# Open Continuity Protocol 0.4

## Consolidated Independent Review

**Document reviewed:** Open Continuity Protocol 0.4 — Consolidated Editor's Working Draft  
**Wire version:** `0.4`  
**Review date:** 12 August 2026  
**Review posture:** independent standards, architecture, schema, security, privacy, consent, implementation, adoption, governance, and editorial assessment  
**Release posture:** current project-authoritative working draft; not an adopted standard, production recommendation, security certification, legal conclusion, or independent-interoperability claim

> **Central finding**
>
> OCP identifies a real interoperability problem and now has a coherent nine-record governed-context core. Its defensible contribution is not generic portable memory; it is a purpose-bound presentation and review protocol that keeps evidence, provider interpretation, scoped acceptance, runtime disclosure, transfer, and action authority separate. OCP 0.4 is suitable for bounded public technical review and implementation experiments, but not for a stable interoperability, security, privacy, or compliance claim.

### Review basis and evidence labels

This report reviews the complete OCP 0.4 source tree: normative prose, all nine core record schemas, shared definitions, HTTP/offline/transfer bindings, profile schema sketches, positive and negative fixtures, semantic vectors, lifecycle/error/event/standards registries, OpenAPI, assertion registry and results, PAM mapping, decision register, architecture and security rationales, migration material, and publication summaries. The historical OCP 0.1 independent review was used as the structural baseline; its findings are not silently treated as current 0.4 defects.

The report uses four evidence labels:

- **Current OCP 0.4 disposition** means a design, schema, binding, mapping, or editorial choice present in this release.
- **Local reference evidence** means the checked-in schemas, fixtures, semantic vectors, registries, and report-accounting checks produced the recorded result against the release source.
- **External standard** means an adjacent specification or authority identified by its primary source and maturity.
- **Implementation evidence required** means prose, schemas, or synthetic vectors cannot responsibly close the question.

The current local evidence is: **27 / 27** JSON Schemas compiled; **23 / 23** positive examples validated; **45 / 45** declared negative examples were rejected; **243 / 243** semantic reference vectors passed; **29 / 29** registry, OpenAPI, and evidence-accounting gates passed; and **107 / 107** assertion rows have one result record. These are source/reference results only. The assertion ledger records **0 implementation passes**, **0 implementation failures**, **63 partial-reference results**, **4 manual-required results**, **3 unavailable results**, and **37 not-executed results**. No identified provider, client, importer, exporter, authorization deployment, cryptographic profile, or independent implementation was the system under test.

---

# Deliverable 1 — Independent executive assessment

## 1.1 OCP in 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 accepted-state writes and never treating context as authority to act.

## 1.2 OCP in one paragraph

OCP addresses the gap between a raw provider archive and the small amount of reviewed context another system needs for a stated task. A client declares its identity, exact delivery instance, plaintext processors, supported processing uses, retention behavior, and related practices; requests specific context views for a machine-coded and human-readable purpose; and receives only what a separate authorization decision permits. The provider records a non-secret receipt, builds an immutable minimized package for one delivery recipient, replaces stable store identifiers with delivery-pairwise or package-local aliases, and preserves distinctions among source evidence, provider interpretation, and accepted context. A client may propose changes, but an immutable review decision and a new context-item revision are required before accepted state changes. OCP also makes transfer loss, source dependence, revocation, deletion reporting, and assurance limits explicit.

## 1.3 Primary user problem

People who switch among or combine AI products must either repeat projects, preferences, constraints, and decisions or disclose broad provider archives that lack purpose limitation, minimization, review state, provenance, safe write-back, and action-authority boundaries. Raw portability moves records; it does not necessarily move a trustworthy, scoped understanding.

## 1.4 Actual protocol boundary

OCP 0.4 standardizes:

1. nine core semantic/workflow records;
2. exact snapshot and live-status references;
3. client declaration → request → external authorization → non-secret receipt → minimized package semantics;
4. typed containment across purpose, selectors, views, recipient, processors, time, retention, processing uses, proposal rights, delegation, and offline use;
5. proposal, immutable review-decision, accepted-revision, supersession, withdrawal, and profile-gated dispute rules;
6. context/evidence/artifact disclosure separation and untrusted-data handling;
7. package-local identity, loss-aware export/transfer, and source-dependence rules;
8. distinct revocation, deletion-report, cryptographic-erasure, and independent-verification claims; and
9. actor-scoped conformance assertions with evidence-status accounting.

OCP does **not** standardize human authentication, identity proofing, access-token issuance, OAuth itself, tool or external-action authorization, agent execution, a universal ontology, artifact storage, universal multi-party authority, new cryptography, legal compliance, or proof of recipient behavior after plaintext disclosure.

## 1.5 Sixty-second real-world example

Avery connects a travel assistant. The assistant declares its publisher, one authenticated client instance, and the model processor that will see plaintext. It requests Avery's accepted lodging preference for one trip, with no raw messages, training, advertising, delegation, or offline use. A separate authorization flow approves only that narrow request. The provider records a non-secret receipt and sends a short-lived package containing one structured preference, package-local identifiers, and its review/provenance relationships. The preference can improve suggestions but cannot authorize a booking. If the assistant learns a new preference, it submits a bounded proposal; Avery accepts, edits, disputes, or rejects it. Later revocation stops new provider-mediated access but does not claim to recall plaintext already delivered.

## 1.6 Reference architecture

```mermaid
flowchart LR
    SRC["Source providers, exports, and APIs"] --> Q["Sandboxed import quarantine"]
    Q --> E["Evidence and provider interpretations"]
    E --> RV["Provider-controlled review"]
    RV --> AC["Accepted context records"]
    CD["Client declaration"] --> REQ["Inert context request"]
    REQ --> AUTH["OAuth, GNAP, OS, or local authorization"]
    AUTH --> GR["Non-secret grant receipt"]
    AC --> PB["Minimizing package builder"]
    GR --> PB
    PB --> PKG["Immutable recipient-bound package"]
    PKG --> CL["Client data channel"]
    CL --> UP["Bounded update proposal"]
    UP --> RV
    AC --> XFR["Loss-aware transfer binding"]
    ACT["Fresh external-action authorization"] -. "separate control plane" .-> CL
```

The decisive boundary is between the **context data plane** and the **authorization/action control plane**. OCP content can inform an application; it cannot release a tool, select a credential, weaken policy, or authorize an external side effect.

## 1.7 Overall verdict

**Verdict: proceed with an explicitly provisional public technical review; do not claim stable interoperability or production assurance.**

- **Publishable as a public 0.x draft?** Yes, as the current 0.4 editor's working draft with its limitations beside the relevant features. It should not be labeled a standard, release candidate, security profile, or production recommendation.
- **Implementable?** The representation, core state model, and reference comparators are sufficiently specified for two teams to build prototypes. Remote authorization, strict raw-JSON parsing, hostile import containment, recipient cryptography, offline protection, and human review still need implementation evidence.
- **Meaningfully differentiated?** Yes, narrowly. PAM and provider formats move memory; OAuth authorizes calls; MCP/A2A carry interactions. OCP's whitespace is scoped acceptance plus purpose-bound minimized presentation, proposal/review write-back, loss-aware movement, and a structural no-action-authority rule.
- **Appropriate scope?** Largely yes. The nine-record core is credible. HTTP/offline/transfer belong in bindings; conversation, artifact, lineage, erasure, continuity observation, human-interaction boundary, complex authority, delegation, credentials, organizations, and live sync belong in complete profiles or future work.
- **Protocol status?** OCP now has objects, state transitions, operations, bindings, error semantics, and conformance assertions, so “protocol family” is justified. Its semantic core should remain transport-neutral.

## 1.8 Five strongest elements

1. **Acceptance is scoped governance state, not truth.** Epistemic basis remains separate from review status and accepted scope.
2. **Authorization is external and operation-time.** Requests and receipts are inert; possession of an OCP object never authorizes access or action.
3. **The disclosure chain is explicit and attenuating.** Exact snapshots, one delivery recipient, declared processors, and typed containment reduce substitution and widening ambiguity.
4. **Accepted-state writes require proposal and immutable review.** Exact targets, bounded proposal rights, and result commitments prevent silent memory mutation.
5. **Assurance language is unusually honest.** Runtime presentation differs from transfer; source URLs differ from preservation; revocation differs from deletion; fixture success differs from implementation conformance.

## 1.9 Ten most serious remaining weaknesses

1. No two independent implementations have exchanged the core or completed a provider-to-provider round trip.
2. Remote Package Security and Offline Package Protection remain unavailable; no executable issuer-authenticity, recipient-confidentiality, key-lifecycle, or downgrade profile exists.
3. Operation-time OAuth/RAR and local-broker bindings have not been exercised against real authorization deployments.
4. The supplied JavaScript validator operates on parsed objects and does not itself prove raw-byte duplicate-member, invalid-UTF-8, lone-surrogate, or full cross-language RFC 8785 handling.
5. Hostile archive, parser, media-decoder, SSRF, secret, prompt-injection, model-channel, and tool-channel behavior has no deployed evidence.
6. The seven non-core profile files are schema sketches or draft profile fragments, not complete Section 33.2 profile contracts with full fixtures and conformance.
7. Multi-party, child/guardian, household, organization, coercion, incapacity, inheritance, and delegated-agent authority remain intentionally unsupported in the baseline.
8. Consent comprehension, accessibility, coercion resistance, and material-change review have not been tested with people.
9. The exact experimental PAM mapping has no machine-readable loss/sidecar fixture suite or two independent adapters; eight of nine OCP records lack even the strongest source-record analogue, and no core record has proven lossless PAM-alone round trip.
10. Neutral namespace, license, patent, contribution, registry, appeals, security-response, funding, and conformance-mark governance are not adopted.

## 1.10 Three highest-risk unresolved decisions

1. **Protection and keys:** the exact remote/offline cryptographic profiles, trust model, recipient-key binding, algorithm agility, rotation, compromise, recovery, and archival migration rules.
2. **Governance and namespace:** durable neutral control of schemas, registries, media types, contributions, intellectual property, security response, and compatibility marks.
3. **Authority beyond one adult's own data:** safe scope, decision thresholds, rights, custody, withdrawal, safety, and legal boundaries for multi-party, organizational, vulnerable-person, and delegated-agent context.

## 1.11 Strongest arguments

**Strongest argument for OCP.** Existing standards can move records, authorize operations, authenticate actors, carry agent messages, or prove selected provenance, but none combines scoped human/policy acceptance, purpose-bound minimized presentation, separate context/evidence/artifact views, controlled proposal/review write-back, loss-aware movement, and an explicit no-action-authority invariant.

**Strongest argument against OCP.** The valuable semantics may be too policy-heavy and expensive for providers to implement consistently; the same market could converge on a smaller PAM-compatible profile plus product-specific consent, leaving OCP as an elegant but unadopted layer and a concentrated privacy target.

## 1.12 Recommended next step

Publish the synchronized 0.4 source package for bounded technical review, then run three prototypes before changing maturity:

1. two independent stacks exchange declaration, request, partial decision, receipt, live status, package, proposal, decision, expiry, and revocation through both OAuth/RAR and a local broker;
2. two independent import/export stacks process hostile archives, preserve unknowns, report losses, and complete A → B → A semantic comparison including PAM sidecar/loss behavior; and
3. accessible mobile and desktop decision flows test recipient/processor comprehension, view separation, retention/training/proposal/offline choices, revocation/deletion limits, and coercion-resistant decline.

## 1.13 Executive scorecard

| Dimension | Score | Explanation |
|---|---:|---|
| Conceptual clarity | 8/10 | The governed-context center and exclusions are explicit; “continuity” still needs public comprehension testing. |
| Problem importance | 9/10 | Repeated setup, context lock-in, and overbroad archive disclosure are durable multi-provider problems. |
| Novelty | 6/10 | Most primitives exist elsewhere; novelty lies in their acceptance, presentation, and write-back composition. |
| Differentiation | 7/10 | OCP has narrow whitespace, but PAM and adjacent protocols constrain any broader memory claim. |
| Protocol coherence | 8/10 | Nine records, exact references, typed containment, lifecycle separation, and bindings form a coherent system. |
| Schema maturity | 8/10 | Twenty-seven schemas and synchronized fixtures are substantial; non-core profiles and strict raw-input behavior remain incomplete. |
| Implementability | 7/10 | The core is buildable, but authorization, hostile import, and protection profiles need prototypes. |
| Security | 7/10 | Strong boundaries and fail-closed rules exist; cryptographic and deployed adversarial evidence does not. |
| Privacy | 8/10 | Minimization, declared processors, aliases, purpose, layered views, and qualified deletion semantics are strong on paper. |
| Interoperability | 6/10 | Representation and an exact PAM mapping exist, but no independent exchange has occurred. |
| Developer experience | 8/10 | Standalone prose, OpenAPI, schemas, examples, registries, errors, and reproducible checks reduce guesswork. |
| User comprehensibility | 7/10 | Required decision dimensions are expressible; real comprehension, accessibility, and coercion evidence is absent. |
| Governance credibility | 4/10 | Vendor neutrality is designed in, but durable governance and IP rules are not adopted. |
| Readiness for public review | 8/10 | Suitable for explicit provisional technical review, not for a standard, certification, or release-candidate claim. |

---

# Deliverable 2 — Prioritized issue register

“Applied” below records the current OCP 0.4 disposition of a finding first raised during review. **Yes** means the architectural or source correction is present in 0.4, not that a deployment has proved the behavior. **Partly** means the source direction exists but a profile, mapping, test facet, independent implementation, or external assurance remains. **Deferred** means the baseline intentionally rejects the claim or moves it to future profile work.

Priorities mean: **P0** foundational blocker to the affected maturity claim; **P1** major requirement before credible broad implementation or assurance; **P2** material improvement; **P3** editorial or future work. A P0 can be source-corrected while still blocking a production or interoperability claim.

The normalized register contains **57 findings: 10 P0, 31 P1, 13 P2, and 3 P3**.

| ID | Priority | Section | Category | Finding | Why it matters | Recommendation | Applied to revised draft? |
|---|---|---|---|---|---|---|---|
| OCP-P0-001 | P0 | 3, 6, 10, 12 | Authorization boundary | context_grant resembles an authorization artifact but is not bound to an enforceable decision and could be mistaken for a bearer credential. | A request or portable receipt could be accepted as authority, enabling confused-deputy access. | Keep requests inert; use OAuth, GNAP, or a local broker; define grant_receipt as non-secret and non-authorizing; authorize every operation at use time. | Yes |
| OCP-P0-002 | P0 | 6, 10, 11 | Package binding | The request, authorization decision, credential, client instance, receipt, and package are not cryptographically or transactionally bound. | Substitution, widening, replay, wrong-audience use, and authorization races remain possible. | Bind the exact request and decision revision, effective-authorization hash, issuer/resource, recipient key, purpose, time, and content manifest. | Partly |
| OCP-P0-003 | P0 | 2, 4, 10 | Authority model | A singular subject and broad steward role cannot express competing rights or establish authority over disclosed data. | One party could approve another person's or an organization's information without a valid basis. | Limit the baseline to competent-adult self-authorization; model aboutness, custody, authority basis, scope, and threshold separately; defer complex cases. | Partly |
| OCP-P0-004 | P0 | 9, 10, 11 | Import security | Prompt injection, poisoning, archive/parser, SSRF, secret, and active-content controls are descriptive rather than testable requirements. | Imported content can control privileged models or tools, leak secrets, corrupt context, or compromise hosts. | Define trust zones, no-network sandboxing, quantitative limits, persistent taint, inert rendering, secret quarantine, and hostile fixtures. | Yes |
| OCP-P0-005 | P0 | 14 | Conformance honesty | The L1-L3 ladder mixes locally testable behavior with unobservable downstream purpose, retention, training, and deletion conduct. | A conformance mark could imply privacy or behavioral guarantees that protocol tests cannot prove. | Split structural, semantic, authorization, import-safety, UX, transfer, binding, and external-assurance claims; label evidence as enforced, declared, attested, or audited. | Yes |
| OCP-P0-006 | P0 | 4.3, Appendix A | Schema architecture | The draft requires one common top-level envelope, but most normative examples omit its required fields. | Independent implementations will choose incompatible shapes and omit security-significant metadata. | Define record, transaction, and manifest envelope families with type-specific required fields; validate every normative example in CI. | Yes |
| OCP-P0-007 | P0 | Appendix A.2 | Semantic invariant | The stated grant_scope >= package_scope prohibition appears reversed and does not define comparison across authorization dimensions. | Literal implementation could forbid safe narrowing while allowing unsafe widening. | Require package_authorization to be a typed subset of effective_authorization; reject unknown or incomparable constraints; publish property-based negative tests. | Yes |
| OCP-P0-008 | P0 | 12.4 | Standards overlap | The draft understates Portable AI Memory v1.0, which already covers memory lifecycle, provenance, grants, signatures, export, and mappings. | OCP risks duplicating its closest adjacent format and weakening its standards credibility. | Publish a bidirectional field-level, loss-aware PAM mapping and prefer an OCP governance/presentation profile unless demonstrated gaps require a separate schema. | Partly |
| OCP-P0-009 | P0 | 2, 4.11, 10.7-10.8 | Third-party and organizational data | The core claims household, relationship, team, organization, and work support without enforceable authority or exfiltration controls. | OCP could normalize private communications and trade secrets into a highly useful disclosure package. | Exclude raw third-party and managed organizational content from the Core Personal Profile and require separately reviewed profiles. | Yes |
| OCP-P0-010 | P0 | 2, 17, 18 | Vulnerable and joint subjects | Child, guardian, assisted-decision, incapacity, deceased-person, household, and joint cases remain unresolved while the role model appears to permit them. | Implementations may advertise support without adequate rights, transition, disagreement, or withdrawal semantics. | Mark these cases unsupported in core and require profile-specific legal, rights, safety, accessibility, threshold, and withdrawal review. | Deferred |
| OCP-P1-001 | P1 | 4, 5 | Epistemic terminology | Canonical context can imply complete identity, objective truth, or a single authoritative winner. | The term encourages dossier thinking and overstates what human or provider acceptance establishes. | Use accepted portable context for governance state and reserve canonical only for deterministic representation or bytes. | Yes |
| OCP-P1-002 | P1 | 4.4 | Object model | Seventeen domain objects are presented as core without complete schemas or interoperability evidence. | A large speculative core slows adoption and produces incompatible lifecycle and security semantics. | Merge claim, goal, decision, instruction, and note into context_item; move conversations, artifacts, credentials, relationships, learning, and lineage into profiles. | Yes |
| OCP-P1-003 | P1 | 4.5, 5 | Typed values | predicate plus unconstrained value cannot reliably encode datatype, language, unit, reference, structured value, qualifiers, or profile semantics. | Round trips and comparisons lose meaning, while free-form strings become a hidden ontology. | Use URI predicates, typed values, qualifiers, profile schemas, and opaque preservation with explicit loss for unsupported semantics. | Yes |
| OCP-P1-004 | P1 | 5.3, 12.6 | Provenance | The provenance array accepts arbitrary objects and its PROV mapping is illustrative only. | Implementations cannot consistently distinguish source, activity, actor, time, transformation, and verification. | Define typed source_record and provenance fields; publish a normative PROV mapping and reference C2PA rather than duplicating it. | Partly |
| OCP-P1-005 | P1 | 4.3, 10.2 | Identifiers and privacy | Global URI requirements conflict with pairwise privacy, and examples disclose stable store and subject identifiers. | Stable identifiers make cross-client correlation and graph joining a built-in capability. | Separate internal IDs, issuer-scoped principals, audience-pairwise subject aliases, and package-local entry IDs; define rotation and merge mappings. | Partly |
| OCP-P1-006 | P1 | Examples, Appendix A | Example validity | Examples contain 24 invalid label-like UUID URNs, five unregistered OCP URNs, an undefined ocp+blob scheme, and two fake SHA-256 values. | Examples are copied into implementations and contradict claims that the draft is buildable. | Use valid synthetic UUID URNs, specified HTTPS or registered identifiers, computed digests, and automated validation of every example. | Yes |
| OCP-P1-007 | P1 | 5, 7, 9 | Lifecycle model | Review status, record state, temporal validity, disclosure eligibility, transfer, withdrawal, revocation, and deletion are blended or listed without complete state machines. | Illegal resurrection, stale use, contradictory histories, and unsafe retries become implementation-defined. | Define orthogonal state dimensions, legal transitions, terminal states, immutable decisions/events, and fail-closed transition errors. | Yes |
| OCP-P1-008 | P1 | 5.7, 7, 11.4 | Concurrency and idempotency | Revision, ETag, stale-write, causal-link, and payload-bound idempotency rules are incomplete. | Concurrent reviewers or providers can overwrite authority decisions or duplicate side effects. | Require monotonic revision, expected revision or If-Match, immutable events, payload-bound idempotency keys, and no last-write-wins for authority. | Partly |
| OCP-P1-009 | P1 | 6 | Request-receipt-package comparison | The three objects differ conceptually but lack a complete containment algorithm and binding chain across all authorization dimensions. | A decision can widen a request or a package can exceed the effective decision in an incomparable dimension. | Define typed comparators for selectors, views, purpose, audience, time, processing, retention, offline use, proposal rights, and delegation; unknown comparison denies. | Partly |
| OCP-P1-010 | P1 | 6.8, 10, consent | Client declarations | Retention, training, processors, logging, derivatives, deletion, and forwarding are unauthenticated requester strings. | The most important privacy terms can change after approval and remain only unverified promises. | Require a signed, versioned, expiring client_declaration; bind its digest into request, receipt, and package; label assurance honestly. | Partly |
| OCP-P1-011 | P1 | 6.9, 12 | Delegation | A delegation string has no child decision, actor chain, attenuation proof, depth limit, or new audience-specific package. | Agents can broaden access, forward context, or obscure the true processor. | Default delegation depth to zero; require established token exchange, strict intersection, a child decision, actor chain, and new recipient encryption per hop. | Deferred |
| OCP-P1-012 | P1 | 6.4, 11.7 | Package kinds | Runtime disclosure and offline export or transfer packages share ambiguous language and security assumptions. | A long-lived archive may be treated as current runtime context or as authorization. | Define distinct runtime, transfer, and offline package types; transfer enters quarantine and carries no runtime or action authority. | Yes |
| OCP-P1-013 | P1 | 10.9-10.10 | Cryptographic package protection | TLS, JCS, and a digest do not specify issuer authentication, recipient confidentiality, signed coverage, key trust, rotation, or algorithms. | A digest can detect change but not who issued a package, and plaintext remains forwardable. | Select reviewed signature and recipient-encryption profiles; define signed view, attachment coverage, key lifecycle, algorithm agility, and interoperable vectors. | Partly |
| OCP-P1-014 | P1 | 10.12 | Local-first security | A loopback service is suggested without app identity, pairing, CSRF/CORS, Host/origin, DNS-rebinding, socket, keychain, or backup rules. | Any local process or hostile browser origin may reach highly sensitive context. | Prefer an OS broker or Unix socket; otherwise require secure pairing, instance keys, strict Host/origin checks, no ambient cookies, CSRF defense, and protected storage. | Partly |
| OCP-P1-015 | P1 | 9, 10 | Parser and content safety | Archive size, path, MIME, recursion, URL fetch, redirect, active content, decoder, and secret-detection limits are absent. | Imports enable denial of service, path traversal, SSRF, malware, parser exploitation, and credential leakage. | Publish quantitative limits and hostile fixtures; parse in a sandbox with no network or ambient credentials; reject traversal, bombs, and active content. | Partly |
| OCP-P1-016 | P1 | 13.3 | Extensions | Unknown non-critical extensions may be preserved or ignored without prohibiting their runtime disclosure, rendering, indexing, or model processing. | Extensions become covert channels around minimization and review rules. | Permit opaque preservation at rest, but prohibit interpretation, rendering, indexing, model use, and disclosure until understood and explicitly granted. | Yes |
| OCP-P1-017 | P1 | 8 | Artifact scope | Artifacts are core objects despite unresolved storage, active-format, rights, chunking, authenticity, decoder, and preservation semantics. | The core expands into backup and media infrastructure with severe parser and rights obligations. | Keep artifact references and preservation state in presentations; move bytes, lineage, storage, chunking, C2PA, and active media to a reviewed profile. | Yes |
| OCP-P1-018 | P1 | 10.7 | Third-party privacy | Third-party content is excluded only by a SHOULD, while pseudonymization is treated as broadly sufficient. | Relationship graphs, presence, and source detail remain re-identifiable and can expose another person. | Prohibit raw third-party content in the Core Personal Profile and protect relationship edges, source details, and omission metadata. | Yes |
| OCP-P1-019 | P1 | 10.8 | Organizational DLP | Custody, source environment, confidentiality, exportability, and organizational policy are optional advisory fields. | A personal context store can become a structured corporate data-loss channel. | Require these controls in an organizational profile and quarantine managed-source content from personal core absent explicit policy authorization. | Deferred |
| OCP-P1-020 | P1 | 3, 6, 10 | Consent and HCI | A human-readable purpose is required, but client identity, processors, material changes, anti-dark-pattern behavior, accessibility, and high-risk confirmation are not. | A technically valid access decision may still be unintelligible, deceptive, inaccessible, or coerced. | Require provider-controlled UI, default deny, separate choices, equivalent decline, material-change re-consent, WCAG 2.2 AA, and comprehension testing. | Partly |
| OCP-P1-021 | P1 | 9.7-9.8 | Deletion evidence | Erasure records omit derivative scope, processors, backups, legal holds, exceptions, verification method, and verifier independence. | A reported-complete status can still create a misleading impression of universal deletion. | Define scoped deletion status records and separate external verification attestations; generate exact qualified UI language and preserve residual-copy warnings. | Partly |
| OCP-P1-022 | P1 | 11 | HTTP binding | The original endpoint sketch lacked complete request/status/event/error contracts. The current source supplies typed create inputs, exact status reads, ETags/preconditions, idempotency, cursor pagination, advertised limits, Retry-After behavior, and exact event-axis schemas; deployment authorization and production behavior remain untested. | Independent clients still require deployed evidence even though the source-level binding is now substantially complete. | Retain the complete OpenAPI/RFC 9457/RFC 9728 source contract and obtain interoperable deployment evidence. | Yes at source; implementation evidence required |
| OCP-P1-023 | P1 | 12 | Standards mappings | Adjacent standards are named, but mappings are mostly prose rather than versioned, testable profiles. | Implementations can claim the same compatibility while serializing different semantics or duplicating existing protocols. | Publish mappings and fixtures for PAM, OAuth/RAR/PRM, MCP, A2A, PROV, C2PA, VC, DPV, Solid, CloudEvents, and OpenTelemetry. | Deferred |
| OCP-P1-024 | P1 | 9.6, 14.5 | Round-trip conformance | Round-trip SHOULD language lacks semantic-equivalence rules, exception manifests, unknown-field behavior, and two-provider evidence. | Portability can silently discard meaning while still being reported as successful. | Define semantic equivalence and explicit loss reports; require independently implemented producer-consumer and provider round trips before stable interoperability claims. | Partly |
| OCP-P1-025 | P1 | 16 | Governance | Neutrality is aspirational; IP terms, contribution rules, registries, appeals, trademarks, conformance marks, and security disclosure remain unsettled. | A commercial sponsor can appear to control a nominally open standard and its conformance oracle. | Adopt public governance and royalty-free IP commitments before stable registries or marks; keep KnowOnce informative and non-privileged. | Partly |
| OCP-P1-026 | P1 | Scope, GDPR, EU Data Act | Legal-claim boundary | Portability language could be read as establishing a legal right over provider inference or third-party and organizational data. | Applicable rights and legal bases are qualified facts that protocol fields cannot establish. | State that OCP may support voluntary portability and governance workflows; never equate protocol conformance with legal compliance; require deployment-specific legal review. | Yes |
| OCP-P1-027 | P1 | 1.4, 4.4, 6.4, 10 | External action authority | Descriptive action, decision, instruction, and credential content can look like current authority to an agent even though context access is not action permission. | A model may treat historical approval or injected prose as permission to send, buy, delete, or invoke tools. | Require external_action_authority to be none in core packages; treat instructions as untrusted data; require separate fresh domain authorization for concrete actions. | Yes |
| OCP-P1-028 | P1 | 2, 6, 11.2 | Client and discovery trust | Provider and client identities are names or URLs without required publisher, client-instance key, authorization-server, resource, or discovery trust bindings. | Provider impersonation, client phishing, authorization-server mix-up, and unsafe discovery become straightforward. | Bind issuer, resource, authorization server, client ID, client-instance key, publisher declaration, and trust method; require exact matching and SSRF-safe discovery. | Partly |
| OCP-P1-029 | P1 | 11.3 | Item retrieval authorization | Direct item retrieval is protected only in prose while stable item identifiers and package references may be enumerable. | Broken object-level authorization can bypass package minimization, field views, expiry, and revocation. | Authorize every item read against the active credential, receipt, client instance, audience, purpose, selector, and field view; disclose only opaque package-local aliases. | Partly |
| OCP-P1-030 | P1 | 7 | Proposal abuse | Proposal rights lack normative rate limits, spam handling, trusted rendering, batch-review limits, and malicious-client quarantine. | Proposal fatigue and deceptive content can turn nominal human review into silent or coerced acceptance. | Rate-limit by client and data class, render in provider-controlled UI, prohibit risky bulk acceptance, bind expected revisions, and retain reversible quarantine. | Yes |
| OCP-P1-031 | P1 | 4.4, 10 | Credentials and capabilities | Credential objects sit near the core without a hard prohibition on raw secrets or a distinction between evidence, references, presentations, and activated capabilities. | Tokens, keys, cookies, and recovery codes can leak into packages, logs, models, or action paths. | Exclude credential and capability transport from core; prohibit raw secrets; require a separately reviewed reference or presentation profile if a use case is proven. | Deferred |
| OCP-P2-001 | P2 | 6.2-6.8 | Purpose and scope vocabulary | Free-form or locally named purposes and scopes cannot be ordered safely across providers. | String-prefix matching or semantic guessing can widen access. | Use URI identifiers, versioned registries or profiles, human descriptions, and fail-closed comparison; publish DPV mapping experiments. | Partly |
| OCP-P2-002 | P2 | 5.5 | Time semantics | Created, observed, acquired, valid, confirmed, review, expiry, supersession, withdrawal, and deletion times are not consistently separated. | Stale or historically scoped context may appear current, and implementations will disagree on precedence and clock behavior. | Separate record time from source time; define precedence, skew, historical mode, review-due behavior, and hard valid-until exclusion. | Partly |
| OCP-P2-003 | P2 | 10.6 | Sensitivity model | One ordinal sensitivity scale cannot represent health, child, intimate, credential, location, work-confidential, or legal constraints. | Distinct risks collapse into one label, and metadata, summaries, embeddings, and derived features may be underprotected. | Combine a baseline handling class with orthogonal category, profile, and policy references; apply controls to content and derivatives. | Partly |
| OCP-P2-004 | P2 | 6.4, 10.11 | Omission and audit privacy | Omission lists and audit category names may disclose that sensitive spaces, relationships, or content classes exist. | Transparency metadata can itself become a compact surveillance dossier. | Coarsen or suppress unauthorized omission metadata; minimize, encrypt, segregate, access-control, and narrowly retain audit records. | Partly |
| OCP-P2-005 | P2 | 11.6 | Events and telemetry | The current source now defines exact reference-first CloudEvents type/axis/transition behavior and prohibited content; low-cardinality OpenTelemetry practice and deployed retention/duplicate handling remain outside the executable release. | Context can still leak through a careless deployment even though the wire event contract is now bounded. | Keep the corrected CloudEvents source contract; add deployment telemetry, retention, duplicate, and reorder evidence before broader claims. | CloudEvents corrected; telemetry evidence deferred |
| OCP-P2-006 | P2 | 11, 15 | Developer experience | The draft lacks a complete OpenAPI contract, media-type plan, capability negotiation, validator UX, CLI, and compatibility matrix. | Developers must reverse-engineer prose and examples, producing incompatible behavior and unsafe error handling. | Ship generated documentation, JSON-Pointer validation errors, OpenAPI, validators, fixtures, media/profile negotiation examples, and a tested compatibility matrix. | Partly |
| OCP-P2-007 | P2 | 17-18 | Future readiness | Speculative agent, household, credential, live-sync, embedding, and rich-media features appear too close to the security-critical core. | Forecasts can destabilize early wire semantics before a use case or two implementers exist. | Keep narrow extension points and threat notes, but defer features until an interoperability need and independent implementers are demonstrated. | Yes |
| OCP-P2-008 | P2 | Appendix C | Provider observations | Provider-export observations are time-sensitive and are not paired with reproducible public synthetic mapping fixtures. | Readers may treat a snapshot as a current vendor guarantee or sufficient evidence of a standards gap. | Date and version observations, state limits, convert lessons into synthetic fixtures, and never publish uncontrolled personal exports. | Partly |
| OCP-P2-009 | P2 | Appendix A, 14 | JSON Schema portability | Schema compilation alone does not ensure UUID, URI, timestamp, strict-required, unknown-property, or duplicate-member behavior is consistent across validators. | The same object can pass one implementation and fail or be interpreted differently in another. | Pin JSON Schema 2020-12 vocabularies, require format assertion where relied upon, close core shapes, define I-JSON processing, and run cross-language validator CI. | Partly |
| OCP-P2-010 | P2 | 11.5 | Error model | The custom error example lacks a complete registered type taxonomy, status mapping, retry semantics, privacy rules, and machine-readable field pointers. | Clients cannot distinguish validation, authorization, conflict, expiry, rate-limit, and transient failures safely. | Use RFC 9457 application/problem+json with stable type URIs, JSON Pointers, request IDs, retry metadata, and privacy-preserving details. | Yes |
| OCP-P2-011 | P2 | 10.9-10.10 | Key recovery and compromise | Key rotation, compromise, recovery assurance, backup encryption, and re-key behavior are suggestions rather than a coherent lifecycle. | Local-first data may become unrecoverable, while weak recovery can become account takeover or package forgery. | Define key status and rotation events, compromise response, recovery assurance metadata, protected backups, revocation, and export/re-key tests. | Deferred |
| OCP-P2-012 | P2 | 7, 9, 11 | Availability and abuse limits | Package building, import graphs, proposals, event streams, recursive references, and audit storage lack consistent quotas and backpressure. | Attackers can exhaust CPU, storage, network, audit capacity, or human review attention. | Require pagination, bounded traversal, quantitative quotas, backpressure, per-client rate limits, safe retry, and privacy-preserving limit errors. | Partly |
| OCP-P2-013 | P2 | 5.3, 9, 14 | Malicious provider detectability | Export, provenance, and audit rules cannot prove that a compromised provider did not alter, omit, or suppress context. | The context provider remains a powerful trust anchor even when packages validate structurally. | Use signed append-only receipts, export exception manifests, and independent verifier tooling; state that these improve detection but cannot prove uncommitted omissions absent transparency infrastructure. | Deferred |
| OCP-P3-001 | P3 | Throughout | Terminology consistency | Provider, source, subject, steward, user, claim, assertion, event, action, preservation, transfer, deletion, and verification are overloaded. | Normative prose changes meaning across lifecycle, security, identity, and adjacent-standard layers. | Adopt one role and object glossary; prohibit aliases in normative sections and qualify preservation, verification, consent, and deletion claims. | Yes |
| OCP-P3-002 | P3 | Throughout | Normative language | Some MUST and SHOULD statements are aspirational, lack an actor or condition, omit failure behavior, or describe off-protocol conduct. | Requirements cannot be implemented or tested consistently under BCP 14. | Give every normative rule an actor, condition, action, failure result, assurance boundary, and test ID; move aspirations into informative rationale. | Partly |
| OCP-P3-003 | P3 | Document structure | Editorial organization | Security rules, open issues, mappings, schemas, examples, and future claims are dispersed, and the source has an unintended near-blank page 35. | Readers miss mandatory behavior and the document appears less mature than its strongest design ideas. | Reorganize by concept, normative rule, schema, edge case, and test; move examples next to rules and complete render QA before publication. | Yes |

The register shows the important 0.4 posture: the original source-level P0 schema, envelope, action-authority, import-boundary, and conformance-accounting defects have been corrected or bounded in the current model; remaining “Partly” and “Deferred” entries are predominantly implementation, cryptographic-profile, mapping, authority-profile, governance, and human-assurance gates. They must not be converted into implementation passes by editorial declaration.

---

# Deliverable 3 — Standards and overlap analysis

## 3.1 Genuine whitespace

OCP occupies **narrow, credible, but not independently proven whitespace**. “Portable AI memory” is not empty territory: PAM defines a portable memory representation; OAuth and related RFCs define remote authorization; MCP and A2A define runtime interaction; Solid addresses Web storage/access; PROV and C2PA address provenance/authenticity; VC and selective-disclosure work address issuer-backed claims; CloudEvents and OpenTelemetry address notifications/observability.

The remaining vertical is the combined lifecycle for:

- preserving source evidence and provider interpretation without promoting either to truth;
- recording scoped acceptance through an immutable decision;
- requesting and authorizing a purpose/view/recipient/time/use-bounded presentation;
- producing a minimized runtime package with no action authority;
- proposing changes without silent accepted-state mutation; and
- moving the governed state with explicit loss and assurance limits.

PAM is the closest overlap. The current exact OCP 0.4 ↔ PAM v1.0 mapping finds that PAM strongly represents source memory, partially represents context items, and weakly approximates spaces and transfer-like packages, but has no semantic equivalent for client declarations, context requests, grant receipts, update proposals, or review decisions. **Eight of nine OCP core records lack even the strongest source-record analogue, and no core record has a proven lossless PAM-alone round trip.** That is a defensible gap only after machine-readable loss/sidecar fixtures and two independent adapters prove it.

## 3.2 Comparison matrix

| Adjacent standard / work | Overlap | OCP distinction | Reuse opportunity | Duplication risk | Required OCP mapping | Current maturity | Recommendation and primary source |
|---|---|---|---|---|---|---|---|
| Portable AI Memory v1.0 | Memory objects, lifecycle, provenance, relations, access metadata, signatures, incremental export | Scoped acceptance, exact decision lineage, client declaration/request/receipt/package/proposal chain, processor disclosure, no-action boundary | Reuse memory/export fields and provider mapping where meanings match | **Highest:** a second generic memory format would fragment the category | Bidirectional field/cardinality/lifecycle map, sidecar, loss report, negative fixtures, A → B → A comparison | Published independent-project specification, 2026-02-17 | Closest baseline; keep mapping experimental until two adapters pass. [PAM v1.0](https://portable-ai-memory.org/spec/v1.0/) |
| Model Context Protocol | Runtime client/server resources, prompts, tools, capabilities, authorization integration | Durable governed context meaning and acceptance are outside MCP's core | Carry OCP media types, references, and narrow operations over MCP | Recreating tools/resources/tasks or treating MCP “context” as OCP state | Resource/media type, operation, auth, error, capability, no-action mapping | Published fast-moving dated specification, 2026-07-28 | Optional binding, not core dependency. [MCP](https://modelcontextprotocol.io/specification/2026-07-28) |
| Agent2Agent Protocol | Agent cards, messages, tasks, artifacts, streaming, asynchronous exchange | OCP defines package meaning, not agent-task execution | Carry OCP package/reference as a Part or Artifact; reuse A2A state | Recreating tasks/messages/artifacts; confusing A2A `contextId` with OCP context | Part/Artifact carriage, digest/deref, task-vs-acceptance state, auth/error rules | Released protocol 1.0; active maintenance | Optional carriage binding. [A2A](https://a2a-protocol.org/latest/specification/) |
| Context Relay Protocol draft | Runtime context gateway, provenance/safety metadata, policy-oriented relay | OCP owns durable reviewed context, acceptance, write-back, and transfer | Track gateway/safety vocabulary and define carriage if implementations demand it | Treating an individual Internet-Draft as settled or merging runtime gateway state into core | Version-pinned runtime-carriage and authority-boundary map | Active individual Internet-Draft; not IETF-endorsed | Monitor; informative only. [CRP draft-00](https://datatracker.ietf.org/doc/html/draft-vidiniotis-crp-core-00) |
| OAuth 2.0 + Security BCP | Delegated protected-resource access and token security | OCP supplies context-specific request/receipt/package semantics | Use OAuth for operation-time remote authorization | Treating `grant_receipt` as token; duplicating grant negotiation | Resource/operation/client-instance/receipt binding, revocation, introspection, audit | RFC 6749 Proposed Standard; RFC 9700 BCP 240 | Normative remote authorization foundation. [OAuth 2.0](https://www.rfc-editor.org/info/rfc6749/) · [Security BCP](https://www.rfc-editor.org/info/rfc9700/) |
| OAuth Rich Authorization Requests | Structured authorization details | OCP defines the typed context details and containment order | Carry OCP request semantics in `authorization_details` | Assuming arbitrary JSON equality or a purpose string enforces policy | Registered/collision-resistant type, exact members, partial approval, comparator, errors | RFC 9396 Proposed Standard | Remote-binding building block, not universal core. [RFC 9396](https://www.rfc-editor.org/info/rfc9396/) |
| OAuth Protected Resource Metadata + AS Metadata | Resource/authorization-server discovery | OCP-specific versions, schemas, bindings, and capabilities | Link OCP discovery to standard protected-resource and AS metadata | Competing well-known semantics or unsafe issuer/resource selection | Exact resource/issuer/AS links, OCP versions/media types, RAR/security capabilities | RFC 9728 and RFC 8414 Proposed Standards | Reuse and link; keep OCP capability document separate in meaning. [RFC 9728](https://www.rfc-editor.org/info/rfc9728/) · [RFC 8414](https://www.rfc-editor.org/info/rfc8414/) |
| OAuth Resource Indicators | Resource audience restriction | Exact OCP protected-resource binding | Bind tokens to the OCP resource | Treating recipient/purpose/package binding as mere OAuth audience | Resource identifier and token audience mapping | RFC 8707 Proposed Standard | Reuse in remote profile. [RFC 8707](https://www.rfc-editor.org/info/rfc8707/) |
| OAuth DPoP | Sender-constrained token replay mitigation | Package authenticity/confidentiality and plaintext behavior remain separate | Use where selected remote profile requires sender constraint | Claiming DPoP prevents package/plaintext forwarding or signs OCP content | Key, nonce, URI normalization, retry, rotation, error mapping | RFC 9449 Proposed Standard | Profile-specific, not universal guarantee. [RFC 9449](https://www.rfc-editor.org/info/rfc9449/) |
| OpenID Connect Core | Human authentication and identity claims over OAuth | OCP references principals, subjects, authorizers, and reviewers without creating identity | Reuse issuer + subject and assurance evidence | Treating `sub` as universal person ID or authentication as authority | Principal refs, issuer/sub tuple, pairwise IDs, linking, assurance provenance | Final 1.0 with errata set 2 | Identity binding only. [OIDC Core](https://openid.net/specs/openid-connect-core-1_0.html) |
| GNAP | Key-bound, stateful grant negotiation and continuation | OCP supplies context vocabulary and a non-secret semantic receipt | Optional binding for richer negotiations | Rebuilding generic grant negotiation in OCP | Permission, continuation, interaction, key proof, revocation, receipt | RFC 9635 Proposed Standard | Optional future binding. [RFC 9635](https://www.rfc-editor.org/info/rfc9635/) |
| UMA 2.0 | User-managed sharing and claims-gathering over OAuth | OCP package and review semantics | Integrate where UMA is already deployed | Making a complex authorization architecture mandatory or equating “user managed” with rights | Resource registration, requesting party, ticket/token/revocation mapping | Kantara Recommendation, 2018 | Compatibility reference/profile only. [UMA 2.0](https://kantarainitiative.org/kantara-initiative-releases-user-managed-access-version-2-0-specifications/) |
| Solid Protocol and ACP/WAC | User-controlled Web resources, containers, linked identity, access policy | OCP is storage-independent and adds governed context/package semantics | Store OCP resources in Pods; reuse HTTP and deployed access controls | Claiming Solid enforces every OCP purpose, downstream-use, time, or evidence rule; forcing RDF | Representation/link/container/media map; capability matrix; offline-copy caveat | Solid 0.11.0 Draft CG Report; ACP 0.9.0 Editor's Draft | Optional storage profile. [Solid](https://solidproject.org/TR/protocol) · [ACP](https://solidproject.org/TR/acp) |
| Data Transfer Project / Initiative | Provider adapters, service transfer jobs, retries, common models | OCP supplies one governed-context data type | Reuse operational adapter/job patterns | Calling infrastructure a normative standard; equating byte transfer with acceptance | Data type, adapter, job/receipt state, partial failure, idempotency | Active open-source initiative | Implementation option. [DTP](https://dtinit.org/docs/dtp-what-is-it) |
| W3C PROV-O | Entity/activity/agent provenance and derivation | OCP adds scoped acceptance, disclosure fitness, preservation and review | Map source/items/import/review/package/transfer to PROV | Creating another universal provenance vocabulary; treating provenance as truth | Entity/activity/agent roles, derivation, revision, invalidation, primary source | W3C Recommendation | Normative semantic mapping baseline. [PROV-O](https://www.w3.org/TR/prov-o/) |
| C2PA 2.4 | Signed content manifests, assertions/actions/ingredients, validation and redaction | OCP adds context acceptance/access and continuity state | Reference C2PA manifests/results for artifacts | Copying C2PA assertions or equating validity with truth, rights, or preservation | Artifact digest/reference, validation, lineage, redaction, repository receipt | Released industry specification, April 2026 | Artifact/lineage profile mapping. [C2PA 2.4](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html) |
| VC Data Model 2.0 + Data Integrity 1.0 | Issuer-verifiable credentials, presentations, proof/status | OCP treats credentials as evidence and keeps acceptance/action separate | Reference native VC/presentation and verification result | Turning every context item into a credential; treating proof as truth or consent | Issuer/holder/subject, status, proof suite, verifier/time/result, disclosed fields | W3C Recommendations, 2025 | Optional Credential Evidence Profile. [VC 2.0](https://www.w3.org/TR/vc-data-model-2.0/) · [Data Integrity](https://www.w3.org/TR/vc-data-integrity/) |
| SD-JWT and BBS cryptosuites | Selective disclosure and holder/key binding | OCP selects package fields across mutable graphs and external artifacts | Use only for compatible credential forms; experiment with BBS | Claiming arbitrary OCP graphs become unlinkable or selectively disclosable by naming a suite | Stable claims, arrays/graphs, salts/proofs, holder binding, status/linkability analysis | SD-JWT RFC 9901; BBS Candidate Recommendation Draft | Optional/experimental. [RFC 9901](https://www.rfc-editor.org/info/rfc9901/) · [BBS](https://www.w3.org/TR/vc-di-bbs/) |
| W3C Data Privacy Vocabulary 2.0 | Purpose, processing, categories, recipients, safeguards, rights, legal bases | OCP needs a small operational application profile and human labels | Reuse stable DPV URIs where applicable | Creating a competing ontology or treating an annotation as legal determination/enforcement | Purpose/category/processing/recipient/duration/safeguard/right map, version/jurisdiction | Final Community Group Report; not W3C Standard | Recommended vocabulary profile, not core ontology. [DPV 2.0](https://www.w3.org/community/reports/dpvcg/CG-FINAL-dpv-20240801/) |
| JSON Schema Draft 2020-12 | Structural JSON validation and schema vocabularies | OCP adds cross-object, lifecycle, authorization, integrity, and package semantics | Use exact schemas, stable IDs, catalogs, and validation output | Calling schema-valid authorized, safe, accepted, or semantically valid | Dialect/vocabularies, format assertion, unknown/null policy, semantic validator | Published specification set | Normative structural layer. [JSON Schema 2020-12](https://json-schema.org/draft/2020-12) |
| I-JSON + JSON Canonicalization Scheme | Interoperable JSON constraints and deterministic JSON bytes | OCP defines exact record/package projections and digest use | Reuse RFC 7493/RFC 8785 and official vectors | Equating canonical bytes with canonical meaning; parsing duplicates before rejection | Raw decoding, number/Unicode rules, exact projection, digest domain, cross-language vectors | RFC 7493 Proposed Standard; RFC 8785 Informational | Required representation basis; implementation evidence still needed. [I-JSON](https://www.rfc-editor.org/info/rfc7493/) · [JCS](https://www.rfc-editor.org/info/rfc8785/) |
| HTTP Message Signatures | Selected HTTP component authentication | Durable OCP object/package proofs persist beyond one exchange | Optional live server-to-server assurance with content digest | Treating it as TLS, OAuth, package signature, or confidentiality | Covered method/URI/authority/content/OCP headers, nonce/time/key/proxy rules | RFC 9421 Proposed Standard | Optional transport-security profile. [RFC 9421](https://www.rfc-editor.org/info/rfc9421/) |
| Problem Details for HTTP APIs | Standard machine-readable HTTP error envelope | OCP supplies registered problem types and safe extensions | Reuse `application/problem+json` exactly | Forking RFC 9457 or leaking sensitive existence/details | Type/status/code/instance/correlation/field pointers/retry/redaction | RFC 9457 Proposed Standard | Adopted in HTTP binding. [RFC 9457](https://www.rfc-editor.org/info/rfc9457/) |
| CloudEvents 1.0.2 | Event envelope and transport bindings | OCP owns lifecycle event types and authoritative records | Use reference/digest-first notifications | Treating event arrival as state, audit, authorization, or exactly-once truth | Source/ID/type/subject/time/schema, ordering, retry, duplicate, privacy | Stable CNCF release | Optional event binding. [CloudEvents 1.0.2](https://github.com/cloudevents/spec/releases/tag/ce%40v1.0.2) |
| OpenTelemetry | Traces, metrics, logs, baggage, GenAI/MCP conventions | OCP needs privacy-safe operational attributes only | Reuse stable HTTP/RPC/GenAI/MCP conventions | Telemetry becoming audit/provenance/consent; raw/high-cardinality context leakage | Bounded names/status, prohibited data, sampling, retention, audit correlation | Released spec 1.60.0; semantic conventions 1.44.0 with mixed stability | Optional observability profile. [OTel](https://opentelemetry.io/docs/specs/otel/) · [SemConv](https://opentelemetry.io/docs/specs/semconv/) |
| SPIFFE + WIMSE work | Workload identity, trust domains, emerging cross-system/agent identity | OCP needs typed role references, not credentials | Reuse deployed workload identity; monitor drafts | Collapsing human, client, workload, agent, model, and provider into “agent identity” | Identifier/trust domain, assurance, rotation, actor/delegation references | SPIFFE 1.15.2; WIMSE WG draft; agent documents are individual drafts | Informative mapping; no universal OCP agent ID. [SPIFFE](https://spiffe.io/docs/latest/spiffe-specs/) · [WIMSE](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) |
| NIST AI Agent Standards Initiative | Emerging interoperability, identity, authorization, and security program | OCP may contribute a governed context artifact | Track terminology, threats, and evaluations | Claiming a NIST agent standard already exists | Future identity/delegation/action-evidence and threat mapping | Initiative/concept paper, not technical standard | Monitor and engage; no conformance claim. [NIST initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative) |
| NIST AI RMF 1.0 + GAI Profile | Voluntary risk governance, measurement, transparency, privacy, provenance | OCP can produce evidence relevant to risk work | Trace controls/tests/evidence to selected outcomes | Claiming protocol features prove organizational risk management | Risk/control/evidence matrix, roles, incidents, oversight, change | Voluntary NIST publications | Governance/assurance mapping only. [AI RMF](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) · [GAI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) |
| GDPR + EDPB portability guidance | Data protection principles and qualified portability rights | OCP may support voluntary workflows beyond Article 20 scope | Build minimization, transparency, correction, retention, rights, accountability hooks | Claiming every inference is legally portable or user acceptance creates a legal basis | Roles/basis, subject/third party, observed/inferred/derived class, rights request/outcome | Binding regulation plus endorsed guidance | Deployment legal input, not compliance claim. [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04) · [EDPB guidance](https://www.edpb.europa.eu/documents/guideline/guidelines-on-the-right-to-data-portability-under-regulation-2016679-wp242_en) |
| EU Data Act | Product/service data access, sharing, cloud switching, interoperability | OCP may help transfer context but is not automatically in scope | Reuse machine-readable transfer, exceptions, switching/audit patterns | Calling it a blanket right to AI memory or ignoring inferred/content exclusions | Data scope/actors/request/destination/restrictions/switching events | Applicable since 2025-09-12; amendments must be rechecked | Design signal only. [EU Data Act](https://eur-lex.europa.eu/eli/reg/2023/2854/oj?locale=en) |
| EU AI Act | Risk-based duties, transparency, records, oversight, monitoring | OCP may supply traceability and review evidence | Export purpose/version/provenance/review/log evidence | Treating OCP conformance as AI Act compliance | Role, intended purpose, system/model version, oversight, incident/correction | Regulation in force with phased application and 2026 amendment | Compliance-supporting evidence only. [AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) · [2026 amendment](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng) |

## 3.3 Architecture implications

1. Keep the nine-record semantic core transport-, storage-, identity-, authorization-, cryptography-, and agent-runtime-neutral.
2. Treat PAM as the first mapping and prove every claimed gap through fixtures and loss accounting.
3. Keep `grant_receipt` as a non-secret decision record; use OAuth/GNAP/local capabilities to authorize operations.
4. Separate context subject, authorizer, reviewer, client, publisher, client instance, delivery recipient, processor, model, workload, source authority, runtime source, and verifier.
5. Build packages reproducibly from exact snapshots and typed comparators; unknown semantics fail closed.
6. Compose PROV, C2PA, VC, and native proofs without collapsing provenance, authenticity, truth, rights, acceptance, or action authority.
7. Keep CloudEvents non-authoritative and OpenTelemetry sparse and privacy-bounded.
8. Require two independent implementations, cross-provider round trips, hostile vectors, and public governance before a stable interoperability mark.

---

# Deliverable 4 — Schema and data-model audit

## 4.1 Audit verdict and exact results

The current OCP 0.4 source defines a closed and substantially buildable representation model. The local reference suite reports:

| Check | Current result | Evidence boundary |
|---|---:|---|
| JSON Schemas compiled | **27 / 27** | Draft 2020-12 compilation in the included JavaScript harness |
| Positive examples valid | **23 / 23** | Included synthetic fixtures only |
| Negative examples rejected | **45 / 45** | Each rejected at its declared structural/semantic rule |
| Semantic reference vectors | **243 / 243** | In-repository object-graph and comparator vectors |
| Registry/OpenAPI/evidence-accounting gates | **29 / 29** | Source consistency, not deployment behavior |
| Assertion rows accounted | **107 / 107** | Zero implementation passes/failures; 63 partial, 4 manual, 3 unavailable, 37 not executed |

The current positive examples are syntactically and schema-valid; there is no current list of invalid normative examples to correct. That is a material improvement over OCP 0.1. It does **not** prove strict raw-byte JSON handling, deployed authorization, cryptographic package protection, parser containment, semantic round trips across independent stacks, recipient conduct, or human comprehension.

## 4.2 Complete current object inventory

| Layer | Object/artifact | Disposition and rationale |
|---|---|---|
| Core record | `context_space` | Keep. Defines a bounded subject/domain/authority evaluation space. Non-personal domains require an authority profile. |
| Core record | `source_record` | Keep. Separates source authority, runtime source, acquisition, verification evidence, availability, sensitivity, and untrusted treatment. |
| Core record | `context_item` | Keep. One typed statement with independent category, epistemic basis, review state, accepted scope, provenance, validity, sensitivity, and lifecycle avoids duplicating “claim” and “interpretation” types. |
| Core record | `client_declaration` | Keep. Supplies the exact recipient/processor/use/retention/training/deletion/contact claims shown and bound to review. It is not proof of conduct. |
| Core record | `context_request` | Keep. An inert, structured desired-access object. |
| Core record | `grant_receipt` | Keep. A non-secret exact decision record linked to external/local authorization; never a token or capability. |
| Core record | `context_package` | Keep. The immutable, minimized, one-recipient runtime presentation. |
| Core record | `update_proposal` | Keep. The only baseline client suggestion path; exact-target and bounded-right semantics prevent direct writes. |
| Core record | `review_decision` | Keep. Immutable outcome, reviewer authority, proposal snapshot, and accepted-result commitment are necessary to audit acceptance. |
| Shared schema vocabulary | `common.schema.json` | Not a record. Supplies exact refs, actors, purposes, recipients, typed values, integrity, lifecycle, and extensions. |
| HTTP binding | discovery, request/proposal/review-decision/transfer create, RFC 9457 problem, exact event notification, OpenAPI | Keep as binding-native shapes. Dedicated create inputs exclude provider-authored state; event branches bind type, axis, and registered transition. |
| Offline binding | offline package manifest + extension template | Keep as archive construction metadata. It is not a domain profile and supplies no executable cryptography. |
| Transfer binding | transfer manifest | Keep outside semantic core. It carries per-entry outcomes/losses and source disposition. |
| Draft schema sketches | conversation, message, artifact descriptor, lineage event, erasure status | Keep clearly labeled as incomplete profile work; validation of a sketch is not full profile conformance. |
| Optional draft profiles | continuity observation, human interaction boundary | Keep observe-only/no-authority. Complete Section 33.2 profile contracts, retention/correction/deletion rules, and hostile/round-trip fixtures remain future work. |
| Conformance artifact | provider-adapter fixture | Keep. It records exact input bytes/digest, deterministic output projection, losses, and semantic digest; it is not a stored OCP record. |

## 4.3 Objects removed, merged, moved, or still missing

| Candidate | Current 0.4 decision | Rationale / remaining need |
|---|---|---|
| Separate `context_claim`, goal, decision, instruction, note | Merged into `context_item` categories | Category is descriptive only. Rich work semantics require a Work Context Profile. |
| `evidence_record` | Replaced by `source_record` plus typed relationships | A separate evidence store type would duplicate source/provenance semantics. |
| Generic `action` | Removed from core; historical behavior belongs in lineage/activity profile | Prevents descriptive history from being confused with permission to act. |
| Generic context `event` | Removed; observations are sources, notifications use CloudEvents | State, evidence, audit, and notification remain distinct. |
| Artifact/content/lineage records | Moved to profile sketches | Blob storage, rights, active media, chunking, custody, preservation, and C2PA are too broad for the core. |
| Conversation/message | Moved to profile sketches | Branch, role, attachment, redaction, and turn semantics need independent round-trip evidence. |
| Credential/attestation | Deferred profile referencing VC/SD-JWT/native credentials | Avoids inventing another proof system and keeps verification separate from acceptance/action. |
| Stewardship/multi-party authority | Deferred profile | Authority basis, thresholds, partitions, disagreement, transition, safety, and law are unresolved. |
| Agent delegation record | Deferred profile | Baseline is exactly `none`; child authorization and attenuation need prototypes. |
| Erasure record | Profile sketch | Deletion report, cryptographic erasure, and independent verification require exact scoped evidence. |
| Capability document | Binding-native discovery, not durable core record | Discovery is operational metadata, not portable accepted context. |
| Provider mapping | Adapter fixture/report, not general record | Mapping semantics are versioned conformance data. |
| Redaction/omission record | Embedded package/source fields for now | Add a standalone record only if interoperable lifecycle evidence demands it. |
| Live sync cursor/delta/merge/fork | Deferred | Revisions, exact snapshots, ETags, and transfer suffice until multi-writer experiments prove more. |

## 4.4 Object relationship model

```mermaid
flowchart TD
    CS["context_space"] --> CI["context_item"]
    SR["source_record"] -->|"supports / contradicts / contextualizes"| CI
    RD["review_decision"] -->|"accepts / changes / rejects"| CI
    CD["client_declaration"] --> CR["context_request"]
    CR --> GR["grant_receipt"]
    AZ["External or local authorization"] --> GR
    GR --> CP["context_package"]
    CI --> CP
    SR -. "only under separately approved evidence view" .-> CP
    CP --> UP["update_proposal"]
    UP --> RD
    TM["transfer manifest binding"] --> CS
    TM --> CI
    TM --> SR
    AP["artifact / conversation / erasure profiles"] -. "profile relationships" .-> CI
```

The arrows are non-equivalent. Source linkage does not establish truth; review linkage establishes scoped acceptance only; receipt linkage records a decision but does not authorize by possession; package delivery permits no action; transfer/import never directly creates accepted context.

## 4.5 Required fields and rationale

| Record | Principal required content | Rationale |
|---|---|---|
| Persistent envelope | `ocp_version`, `schema_uri`, exact `type`, `id`, positive `revision`, `created_at`, `created_by`, `extensions` | Selects one validator, supports immutable revisions, and prevents a loose universal envelope. |
| `context_space` | name, subjects, domain, authority model, lifecycle | Defines where acceptance and authority policy apply. |
| `source_record` | source type, source authority, runtime source, acquisition method/time, trust and instruction treatment, availability, sensitivity, lifecycle | Keeps origin, capture/transformation, verification, and acceptance separate. |
| `context_item` | subjects, exact space snapshot, category, typed statement, epistemic basis, review, provenance, sensitivity, lifecycle | Makes meaning and governance inspectable without a universal ontology. Accepted items require exact decision and accepted scope. |
| `client_declaration` | client/publisher, instance and processor capabilities, retention/use/training/offline/proposal/delegation support, deletion/privacy/security contacts, validity, assurance | Lets the provider show and bind the same machine-readable client claims the user reviewed. |
| `context_request` | exact declaration snapshot, delivery recipient, processors, purpose, selectors, views, time, retention, processing uses, offline, proposal rights, delegation | Fully expresses desired disclosure while remaining inert. |
| `grant_receipt` | exact request and decision refs, authorizer/authority basis, approved/denied selections, recipient/processors, purpose/time/use/retention/proposal/delegation/offline, live status | Records exact attenuation and supports current-status checks without becoming authority. |
| `context_package` | exact receipt snapshot/live status, purpose, recipient/processors, entries, omissions/warnings, time/use/retention/proposal/delegation/offline, integrity, `external_action_authority: "none"` | Prevents obligations and boundaries from disappearing at delivery. |
| `update_proposal` | submitter, exact receipt/live status, operation, exact target where required, sources, proposed content where required, status | Enforces bounded, race-safe proposal semantics. |
| `review_decision` | exact proposal, reviewer, authority basis, outcome, time, and accepted-result commitment only for accepting outcomes | Prevents rejecting decisions from producing accepted state and binds the exact accepted scope/result. |

## 4.6 Current schema and versioning gaps

1. The JavaScript reference validator receives already parsed objects. A separate strict raw-byte lane is still required for duplicate-member, invalid UTF-8, BOM, lone-surrogate, depth/size, and numeric-boundary evidence.
2. RFC 8785 behavior needs official vectors in at least two independent language stacks. Local digest agreement is only partial evidence.
3. Evidence/artifact embedded package content requires a pinned second validation pass against `content_schema_uri`; a URI alone cannot dynamically validate JSON Schema content.
4. The seven profile files need complete versioned profile documents, authority/privacy/threat models, comparisons, lifecycle/errors, unknown/downgrade rules, and positive/negative/hostile/round-trip fixtures before profile claims.
5. Durable public schema/registry/media-type namespaces, redirect/archival policy, compatibility commitments, and deprecation governance are unresolved.
6. Package/offline cryptographic coverage, signer/recipient trust, key status, rotation, recovery, downgrade, and executable vectors remain outside the current schemas.
7. Pairwise alias construction is outcome-constrained but the project still must select and test CSPRNG mapping, keyed domain-separated derivation, or both, including rotation and recovery.
8. Multi-party/organizational authority and high-risk sensitive categories remain correctly unavailable without dedicated profiles.

## 4.7 Example and conflict disposition

The historical invalid UUID-like labels, fake digests, universal-envelope contradictions, undefined schemes, reversed subset notation, arbitrary provenance, and request/receipt/package drift from OCP 0.1 are not present in the current 0.4 normative fixture set. Current fixtures demonstrate the nine core records, independently assessed and self-declared clients, HTTP discovery/problem shapes, offline and transfer manifests, adapter behavior, and the two optional profile sketches.

The negative corpus currently covers exact-reference digest absence, delivery-recipient shape, invalid layer/disclosure combinations, missing content schemas, missing untrusted markers, unsupported verification claims, proposal attenuation, non-circular offline construction, exact archive membership, accepting-decision linkage, no-action authority, declaration binding, stable-term removal, content-carrier exclusivity, baseline delegation, path traversal, closed members, live grant status, result-commitment branch rules, accepted-scope commitment, verification-result coherence, assurance independence, alias uniqueness, evidence typing, forged create states, review/scope axis consistency, and proposal branch exclusivity.

Those fixtures establish that the current model can express and reject the named cases. They do not prove that a real parser, authorization service, package consumer, model runtime, tool gateway, archive library, or recipient exhibits the required zero-leakage and zero-side-effect behavior.

## 4.8 Semantic rules beyond JSON Schema

The semantic lane must continue to enforce:

1. exact `snapshotMatches` across declaration, request, receipt, package, proposal, source, and review relationships;
2. declaration → request → receipt → package containment for every dimension, including exact purpose text and order-independent processor sets;
3. one delivery recipient/client instance and complete approved plaintext processors;
4. accepted item → accepting decision → exact accepted-result/scope commitment;
5. package-local reference closure, alias uniqueness, and no stable identifier/digest leakage;
6. bounded proposal operations, selectors, target/source rights, and live receipt status;
7. strict time ordering and no package lifetime beyond its request/receipt;
8. exact offline physical-member rules and non-circular signed-view construction;
9. deterministic adapter mapping/loss/digest behavior;
10. unknown critical semantics fail closed and unknown noncritical transfer data remains inert or loss-reported; and
11. no OCP object or content value can become external-action authority.

## 4.9 Corrected schema set and explicit gap register

The current 27 files are the corrected 0.4 schema set. No additional core record schema is recommended before implementation evidence. The rationale is allocation by interoperability responsibility:

| Schema group | Current correction | Rationale |
|---|---|---|
| Shared definitions + nine core records | Closed concrete types, exact version/schema/revision identity, typed values/refs/recipients/purposes, explicit extensions | Standardizes only semantics every core producer/consumer must share. |
| Seven HTTP create/discovery/problem/event schemas | Binding-native input, exact event, and RFC 9457 shapes; callers cannot choose provider-authored lifecycle state | Prevents authority/state injection and avoids forcing HTTP objects into the record envelope. |
| Offline and transfer manifests | Exact archive members, payload/security separation, per-entry outcomes/losses | Archive/transfer mechanics have threats and lifecycles different from runtime packages. |
| Seven profile schemas | Retained as explicitly draft sketches | Preserves useful design work without pretending incomplete domain/security semantics are core or conformant. |
| Adapter fixture | Exact raw input, deterministic output projection, digests, and losses | Mapping reproducibility is conformance evidence, not another persistent OCP object. |

| Gap category | Current 0.4 disposition | Required next action |
|---|---|---|
| Inconsistent field definitions | Corrected in core: purpose, recipient/processors, epistemic basis, source/runtime roles, exact/live refs, target semantics | Enforce the same vocabulary in every future profile and mapping. |
| Schema conflicts | Core/prose/fixtures are synchronized; dynamic evidence/artifact content validation and raw-input decoding remain outside pure shape validation | Add pinned second-pass schema resolution and strict raw-byte/cross-language lanes. |
| Lifecycle gaps | Ten lifecycle models are registered; complex profile and deployed transition behavior remain unproved | Complete profile-specific transitions/errors and execute every legal/illegal pair in identified systems. |
| Relationship gaps | Core exact chains and package-local closure are defined; multi-party, credential, delegation, rich lineage, and live-sync graphs remain deferred | Add only through versioned profiles with authority and round-trip evidence. |
| Privacy gaps | Core Personal, minimization, aliases, processors, views, and bounded assurance are defined; coercion, organizational, child, joint, and recipient behavior remain | Maintain unsupported defaults; require specialist profiles, human evaluation, and external assurance. |
| Versioning gaps | Wire/version/schema/profile dimensions are separated; the `https://opencontinuity.org` working-draft namespace is selected, while ownership, redirects, compatibility, and deprecation policy remain provisional | Adopt neutral namespace and registry governance before stable labels. |

---

# Deliverable 5 — Protocol lifecycle and state-machine audit

## 5.1 Common state-machine rules

The lifecycle registry states a sound common rule: **only listed transitions are legal**. Each transition is atomic, revision-checked, idempotent for the same operation/input, and emits the named privacy-minimized audit event. Every unlisted pair—including any terminal-to-active transition—is illegal and returns the registered illegal-transition or stale-revision error without partial mutation.

Record lifecycle, review status, temporal validity, disclosure eligibility, source availability, transfer status, and deletion evidence are orthogonal. Arrival time is not causality. Immutable snapshot, revision/digest, predecessor/supersession relationship, and current live status decide processing.

## 5.2 Context request

```mermaid
stateDiagram-v2
    [*] --> submitted
    submitted --> awaiting_decision: ocp.request.awaiting_decision
    submitted --> withdrawn: ocp.request.withdrawn
    submitted --> superseded: ocp.request.superseded
    awaiting_decision --> partially_approved: ocp.request.partially_approved
    awaiting_decision --> approved: ocp.request.approved
    awaiting_decision --> denied: ocp.request.denied
    awaiting_decision --> expired: ocp.request.expired
    awaiting_decision --> superseded: ocp.request.superseded
    partially_approved --> approved: ocp.request.approved
    partially_approved --> denied: ocp.request.denied
    partially_approved --> expired: ocp.request.expired
```

**Illegal examples:** client-created approval; approved/denied/expired/withdrawn/superseded → active; purpose, declaration, recipient, processor, view, use, or expiry substitution in place. A materially changed request is new. **Audit:** the label on every arrow is the required event; events include record ID/revision/correlation and omit raw context and free-text purpose.

## 5.3 Grant receipt

```mermaid
stateDiagram-v2
    [*] --> active
    active --> suspended: ocp.grant.suspended
    suspended --> active: ocp.grant.reactivated
    active --> expired: ocp.grant.expired
    suspended --> expired: ocp.grant.expired
    active --> revoked: ocp.grant.revoked
    suspended --> revoked: ocp.grant.revoked
    active --> superseded: ocp.grant.superseded
    suspended --> superseded: ocp.grant.superseded
```

**Illegal examples:** terminal → active; widening or renewal in place; changing exact request/declaration/decision constraints without new review; authorizing by receipt possession. Suspension denies package creation and item reads. **Audit:** suspension, reactivation, expiry, revocation, and supersession events plus operation-time authorization check/failure records; tokens and detailed context are excluded.

## 5.4 Runtime context package

```mermaid
stateDiagram-v2
    [*] --> built
    built --> available: ocp.package.available
    built --> rejected: ocp.package.rejected
    available --> delivered: ocp.package.delivered
    available --> expired: ocp.package.expired
    delivered --> expired: ocp.package.expired
    available --> invalidated: ocp.package.invalidated
    delivered --> invalidated: ocp.package.invalidated
```

Package bytes are immutable. Status lives in an authorized status service/event stream. **Illegal examples:** editing after `built`; expiry later than receipt; reuse for another recipient/client instance/purpose; `expired` or `invalidated` → available; marking delivered plaintext deleted/recalled. **Audit:** available, rejected, delivered, expired, invalidated, verification failure, and authorized dereference. `delivered` is not proof of use, retention, non-forwarding, or deletion.

## 5.5 Update proposal

```mermaid
stateDiagram-v2
    [*] --> submitted
    submitted --> under_review: ocp.proposal.under_review
    submitted --> withdrawn: ocp.proposal.withdrawn
    submitted --> expired: ocp.proposal.expired
    submitted --> superseded: ocp.proposal.superseded
    under_review --> deferred: ocp.proposal.deferred
    deferred --> under_review: ocp.proposal.under_review
    under_review --> accepted: ocp.proposal.accepted
    under_review --> accepted_with_changes: ocp.proposal.accepted_with_changes
    under_review --> rejected: ocp.proposal.rejected
    under_review --> disputed: ocp.proposal.disputed
    disputed --> under_review: ocp.proposal.under_review
    under_review --> expired: ocp.proposal.expired
    deferred --> rejected: ocp.proposal.rejected
    deferred --> withdrawn: ocp.proposal.withdrawn
    deferred --> expired: ocp.proposal.expired
```

Proposal bytes are inert and immutable. Accepting outcomes create a separate review decision and new accepted-item revision. Baseline operations are create and revise; accepted-context withdrawal is profile-gated until an operation-specific decision/tombstone result is defined. **Illegal examples:** client-supplied `accepted`; create proposal with target; revise without exact target; unsupported withdrawal; stale target accepted; rejected → accepted; non-accepting decision with result commitment; silence/timeout as acceptance. **Audit:** every arrow, stale target, attenuation failure, rate limit, source quarantine, and resulting decision/item references.

## 5.6 Accepted context

```mermaid
stateDiagram-v2
    [*] --> active
    active --> superseded: ocp.context.superseded
    superseded --> tombstoned: ocp.context.tombstoned
    active --> withdrawn: ocp.context.withdrawn
```

The baseline review axis is exactly `candidate` or `accepted`; dispute/reaffirmation requires a registered profile with typed immutable decision, authority, scope-retention, revision, and event rules. `superseded`, `withdrawn`, and `tombstoned` belong only to record lifecycle. Acceptance always names an exact accepting decision and accepted scope. **Illegal examples:** provider inference → accepted without decision; accepted scope mutation without a matching result commitment; unprofiled dispute/reaffirmation; lifecycle values placed on the review axis; in-place statement rewrite; last-write-wins conflict resolution; withdrawn/tombstoned resurrection. **Audit:** candidate creation, acceptance outcome, supersession, withdrawal, tombstone, validity/review warning, and disclosure block.

## 5.7 Artifact descriptor profile

```mermaid
stateDiagram-v2
    [*] --> source_dependent
    source_dependent --> referenced: ocp.artifact.referenced
    source_dependent --> preservation_pending: ocp.artifact.preservation_pending
    referenced --> preservation_pending: ocp.artifact.preservation_pending
    preservation_pending --> managed_copy: ocp.artifact.copy_verified
    managed_copy --> verification_due: ocp.artifact.verification_due
    verification_due --> managed_copy: ocp.artifact.copy_verified
    verification_due --> unverifiable: ocp.artifact.unverifiable
    source_dependent --> lost: ocp.artifact.lost
    referenced --> lost: ocp.artifact.lost
    managed_copy --> withdrawn: ocp.artifact.withdrawn
```

This is a draft-profile lifecycle, not core conformance. **Illegal examples:** URL → managed copy without retrievable bytes/read/digest; integrity failure silently returning to available; source loss represented as deletion; C2PA validity treated as truth, rights, or permanence. **Audit:** reference verification, copy verification/failure, source loss, re-verification, migration/repair as new lineage revisions, rights/availability change, and scoped deletion evidence.

## 5.8 Import

```mermaid
stateDiagram-v2
    [*] --> received
    received --> quarantined: ocp.import.quarantined
    received --> aborted: ocp.import.aborted
    quarantined --> parsed: ocp.import.parsed
    quarantined --> rejected: ocp.import.rejected
    quarantined --> aborted: ocp.import.aborted
    parsed --> mapped: ocp.import.mapped
    mapped --> review_required: ocp.import.review_required
    review_required --> accepted: ocp.import.accepted
    review_required --> rejected: ocp.import.rejected
```

Here `accepted` means the import job outcome, not that imported material becomes accepted context. Promotion still creates source records/candidate items and uses review decisions. **Illegal examples:** received/parsed/mapped → accepted context; signature → truth; parser failure → promotion; unknown meaning → guessed semantics; network fetch or active execution during parse. **Audit:** limits, quarantine, parser/scanner outcome, mapping/losses, unknowns, review outcome, cleanup/rollback, and zero privileged effect.

## 5.9 Transfer

```mermaid
stateDiagram-v2
    [*] --> prepared
    prepared --> delivered: ocp.transfer.delivered
    prepared --> aborted: ocp.transfer.aborted
    delivered --> importing: ocp.transfer.importing
    delivered --> aborted: ocp.transfer.aborted
    importing --> validated: ocp.transfer.validated
    importing --> validated_with_exceptions: ocp.transfer.validated_with_exceptions
    importing --> rejected: ocp.transfer.rejected
```

**Illegal examples:** delivered → validated without destination verification; validated-with-exceptions shown as lossless; transfer archive → accepted context; source deletion implied by delivery; missing/unsupported entries omitted from the loss report. **Audit:** preparation, delivery, import start, each entry outcome, exception/loss report, validation/rejection, destination receipt, source-disposition decision, and round-trip comparison.

## 5.10 Revocation

```mermaid
stateDiagram-v2
    [*] --> requested
    requested --> acknowledged: ocp.revocation.acknowledged
    requested --> failed: ocp.revocation.failed
    acknowledged --> effective: ocp.revocation.effective
    acknowledged --> failed: ocp.revocation.failed
```

**Illegal examples:** effective → active; provider-mediated package/read/proposal after effective time; notice represented as recipient deletion/non-use; offline plaintext represented as recalled. **Audit:** request, acknowledgement, effective time/revision, credential/continuation coordination, downstream notice attempts, failure, and propagation report. The enforceable core result is no future authorized provider operation.

## 5.11 Erasure status profile

```mermaid
stateDiagram-v2
    [*] --> requested
    requested --> acknowledged: ocp.erasure.acknowledged
    acknowledged --> reported_complete: ocp.erasure.reported_complete
    acknowledged --> partially_complete: ocp.erasure.partially_complete
    acknowledged --> rejected: ocp.erasure.rejected
    acknowledged --> legal_retention_exception: ocp.erasure.legal_retention_exception
    reported_complete --> independently_verified: ocp.erasure.independently_verified
    partially_complete --> independently_verified: ocp.erasure.independently_verified
```

This is a draft-profile vocabulary. “Independently verified” requires a distinct evaluator and scoped method/evidence; it does not mean universal deletion. **Illegal examples:** request/acknowledgement shown as deleted; provider self-report shown as independent; one destroyed key shown as universal erasure; backups, processors, derivatives, logs, training, or legal exceptions omitted from scope. **Audit:** exact party/data/derivative/copy scope, acknowledgement, completion/partial/rejection/exception, reporter, evidence, verifier relationship/method/result, and qualified UI language.

## 5.12 Lifecycle conformance focus

For every model, a credible behavioral harness must enumerate all legal transitions and reject every other pair while proving: no unauthorized bytes disclosed; no partial mutation; correct revision/ETag and idempotency behavior; correct minimized audit event; terminality; replay/stale failure; package/decision/action separation; and revocation/deletion language no stronger than the evidence. The current registry and semantic vectors define that requirement; they are not evidence that a real service satisfies it.

---

# Deliverable 6 — Security and privacy review

## 6.1 Bottom-line verdict and threat model

OCP 0.4 has a credible **specification-level** security and privacy architecture: exact and live references are distinct; recipient and processor roles are distinct; all context is untrusted data; accepted-state writes require review; authorization is external and operation-time; runtime identifiers are pairwise/local; and revocation/deletion claims are bounded. It is not a security profile or evidence of secure deployment. The most important unavailable work is executable remote/offline package protection; the most important unexecuted work is hostile parser/model/tool containment and real authorization/recipient behavior.

**Protected assets:** accepted and candidate context; raw evidence; third-party and organization data; artifacts and credentials; identity/authority relationships; requests, authorization decisions, receipts, packages, proposals and decisions; keys; transfer/deletion evidence; and privacy-sensitive audit metadata.

**Threat actors:** malicious or overreaching clients; compromised agents/models/processors; malicious source/context providers; compromised adapters/parsers/dependencies; unauthorized local processes/browser origins; dishonest recipients; coerced or unauthorized reviewers; abusive partners/guardians/employers/admins; network attackers; and legitimate recipients that breach declared terms.

**Trust boundaries:** source → importer; raw bytes → parser; parsed data → candidate mapping; model → review UI; principal → authorization service; authorization service → context provider; provider → one client instance; client → processors/models; parent → delegated agent; online system → offline package; personal → organizational environment; and source provider → destination transfer.

## 6.2 Required abuse-case analysis

| ID | Threat actor | Target and attack path | Affected objects | Likely impact | Current 0.4 control | Missing control / evidence | Required normative or profile requirement | Residual risk | Practical conformance test |
|---|---|---|---|---|---|---|---|---|---|
| T-01 | Overreaching client | Vague “personalization,” excessive views, hidden processors/training, repeated requests | declaration, request, receipt, package | Dossier, surveillance, coerced disclosure | Exact declaration; meaningful purpose; typed views/uses; default attenuation; processor list | Real anti-dark-pattern, cooldown, accessibility, and comprehension evidence | Provider-controlled, unbundled, default-deny display; equivalent decline; material-change re-review; repeated-request limits | Economic/social pressure can still influence choice | Mutate purpose, processor, training, retention, view; require new review/no package; human UX study |
| T-02 | Client/processor | Forwards ciphertext, plaintext, URL, token, or summary to another service/agent | package, receipt, entries | Uncontrolled copies, purpose drift, hidden processing | One delivery recipient/instance; approved processors; package-local aliases; baseline delegation `none` | Executable recipient crypto; post-decryption control cannot generally be proved | New authorization, receipt, aliases, and package for each independent recipient; no bearer URLs/secrets; honest assurance labels | Intended recipient can copy plaintext | Wrong-key/peer-instance/undeclared-processor vectors; downstream behavior remains external assurance |
| T-03 | Malicious source/provider/user | Inserts false or manipulative memory and seeks promotion | source, candidate item, proposal, decision | Harmful personalization, discrimination, reputational/financial harm | Import remains source/candidate; epistemic basis; exact provenance; review decision | Reviewer error and malicious-provider omission remain | Signatures prove source only; no auto-accept for high-risk inference; preserve contradictions and adapter method | A reviewer may accept false data | Signed poison still remains candidate; nonaccepting decision cannot produce accepted item |
| T-04 | Content author/source | Instructions hidden in HTML, code, filename, metadata, OCR, transcript, schema extension, or summary | source, package, proposal, model/tool boundary | Exfiltration, policy override, tool action, silent write | `instruction_treatment: untrusted_data`; data/control split; no action authority; inert renderings | No deployed parser/model/tool proof | No imported/package content in policy/tool/credential channels; sandboxed rendering; deterministic action gateway outside model | Prompt injection cannot be eliminated; client may violate architecture | Multi-carrier hostile corpus proves zero tool/network/policy/accepted-state effect |
| T-05 | Impersonating provider/client/AS | Spoofed discovery, names, redirects, issuer, client instance, verifier | discovery, declaration, request, authorization, receipt, package | Credential/context theft, phishing, mix-up | Typed roles; exact resource/issuer expectations; declaration snapshots; verifier identity rules | Real trust anchors, publisher validation, SSRF-safe discovery, key profiles | TLS identity; exact issuer/resource/client-instance match; trusted display; no display-name authorization | A compromised trusted issuer can deceive | Wrong issuer/resource/key/publisher/verifier; redirect/rebinding vectors |
| T-06 | Malicious/compromised adapter | Changes meaning, drops unknowns/provenance, invents links or preservation | source, item, transfer, mapping report | Semantic corruption, lock-in, excessive disclosure | Exact raw bytes/digest; source authority/runtime source; deterministic expected projection/losses | Only one reference fixture; no two independent adapters | Version/digest adapter identity; exact input/output; unknown quarantine; no acceptance; per-path loss report | Colluding adapter/provider can fabricate consistent records | Raw byte and semantic digest mismatch; unknown/loss vectors; two-adapter A → B → A |
| T-07 | Stale source/provider | Old relationship, medical constraint, job search, credential, or decision shown current | source, item, receipt, package | Unsafe decisions and privacy exposure | Distinct validity/acquisition/review times; current package exclusions/warnings; live status | Complete deployed clock/skew/status evidence | Parsed instant comparison; expired excluded; review-due warned; historical profiles state evaluation time | Nonconfirmation does not prove falsehood | Boundary/skew/expired-source/declaration/receipt/package vectors |
| T-08 | Multiple recipients/data broker | Joins stable IDs, timestamps, rare traits, digests, spaces, relationships | package, audit, transfer | Re-identification and dossier construction | Delivery-pairwise and package-local aliases; stable store IDs/digests prohibited; telemetry minimization | Alias algorithm/rotation not selected; semantic content itself identifies | ≥128-bit unpredictable aliases or keyed domain-separated PRF; purpose/instance/epoch domains; no raw IDs | Content and graphs remain linkable | Cross-recipient/instance/epoch nonreuse, predictability, internal-substring and digest-leak tests |
| T-09 | User/client/importer | Discloses another person's messages, photos, health/location/contact details | source, conversation, artifact, relationship, package | Privacy, safety, and legal harm | Core Personal authority boundary; layered views; third-party restrictions; non-disclosing omissions | Full multi-party profile and real policy enforcement | Raw third-party sensitive content excluded from baseline; pseudonymization not authority; per-item rights in later profile | Subject-focused facts may still identify another person | Second-subject/raw-message/contact/location/health fixtures omitted or quarantined |
| T-10 | Employee/personal provider | Imports managed repository, work chat, customer data, or secrets | source, artifact, transfer | Trade-secret and customer-data exfiltration | Organization/mixed data unsupported in baseline; source/environment/custody hooks; secret prohibition | Organizational authority/DLP profile and deployed controls | Default deny/quarantine for managed source; explicit organization policy decision, custody, classification, exportability, retention | Ownership/classification disputes remain external | Managed/mixed-source fixtures denied without profile; no sensitive detail in error/audit |
| T-11 | Household/team member | Approves shared preference, artifact, message, or decision over another's objection | space, item, decision, package | Misrepresentation and privacy violation | Non-personal domains require profile; no universal steward claim | Authority sets, thresholds, partitions, member exit, dispute UX | Joint data unsupported in core; profile must define each right, threshold, withdrawal and unresolved-state block | Protocol cannot settle genuine disputes | Missing/insufficient co-authority blocks review/package; member withdrawal tests |
| T-12 | Guardian/service | Treats guardian as owner; fails to transfer rights as child matures | space, authority, package, audit | Surveillance and developmental-rights harm | Minors/guardians explicitly deferred | Child-rights, assent, privacy partitions, age/capacity transition, jurisdiction review | Baseline rejects unsupported guardian authority; dedicated safety/legal/accessibility profile required | Capacity and best interest are contextual | Unsupported authority fails; transition/assent tests only in reviewed profile |
| T-13 | Partner/guardian/employer/admin | Uses valid credentials, recovery, audit, or review under coercive control | authorization, declaration, package, recovery, audit | Monitoring, impersonation, physical/psychological danger | No coercion-detection claim; high-risk profiles deferred; non-disclosing denial allowed | Specialist threat model, private exit, notification safety, recovery separation | High-risk user presence; private/non-disclosing denial; separate recovery and context authority; safety-reviewed UI | Cryptography cannot prove free choice | Human safety review, safe-denial/non-notification scenarios; no automated “uncoerced” claim |
| T-14 | Provider/client/model | Infers health, politics, religion, sexuality, finance, employment, psychology | source, interpretation, embedding, proposal, package | Discrimination and surveillance | Interpretation separate; sensitivity; no automatic acceptance; view/purpose controls | Category-specific policy/assurance and recipient inference remain | Sensitive inference method/version/provenance; explicit review; no baseline disclosure without profile/decision; derivatives protected | Recipient may infer from permitted data | High-risk inference remains candidate/restricted; derivative/embedding leakage tests |
| T-15 | Parent/delegated agent | Broadens scope, merges unrelated packages, hides actor chain, reuses parent object | authorization, receipt, package, proposal | Privilege escalation and hidden processing | Core delegation exactly `none`; processors gain no OCP rights | No Delegation Profile or child-authorization implementation | Authenticate child; new authorization/receipt/package/key/aliases; strict intersection; root/parent/actor chain; depth bound | Authorized recipients can pool plaintext | Depth-zero denial; every widened child dimension fails; new child package required |
| T-16 | Thief/nonconforming client | Replays expired/revoked/offline package on another instance | package, status, keys | Continued access after decision ends | Runtime offline prohibited; exact receipt/status/time/instance; no recall claim | Executable recipient crypto and hardware/online enforcement absent | Reject wrong recipient/time/status; no one-time/offline-revocation claim without evaluated mechanism | Authorized client can retain decrypted plaintext | Expiry/revocation/wrong-instance/wrong-key/downgrade vectors; UI states limits |
| T-17 | Key thief/recovery attacker/user error | Steals or loses device, signing/encryption/recovery key | store, package, signatures, decisions | Disclosure, forgery, lockout, unrecoverability | Profile requirements mention key lifecycle; crypto classes unavailable | Concrete key issuance/storage/rotation/compromise/recovery profile | Separate key domains; hardware/OS protection where appropriate; rotation/revocation/re-encryption; disclosed recovery tradeoff | Sole control and perfect recovery cannot both be guaranteed | Old/new overlap, revoked/lost/wrong recovery, backup restore, alias/key separation tests |
| T-18 | Malicious context provider | Alters accepted state, suppresses corrections, over-issues packages, lies in export | all records/history | Manipulation, surveillance, denial of portability | Exact revisions/digests/decisions; exception reports; independent comparison possible | Transparency/independent commitment and actual verifier ecosystem absent | Immutable signed receipts under future profile; export exception manifest; independent verifier; no completeness overclaim | Provider can omit before committing | Tamper/substitution/omission comparison; signed history only after executable profile |
| T-19 | Source-provider failure | Provider closes, URLs/exports change, account vanishes, format becomes unreadable | source, artifact, provenance | Broken evidence and misleading continuity | Availability/custody separate; URL not preservation; transfer losses | Preservation profile, format migration, periodic verification deployment | Source-dependent becomes unavailable; managed copy requires retrievable bytes/read/digest/time; preserve lineage | Bytes may survive while rights/decoder/context do not | Unavailable source, stale verification, digest mismatch, migration-as-new-version tests |
| T-20 | Dishonest recipient/provider | Claims deletion while backups, logs, embeddings, training, derivatives, processors remain | erasure status, declaration, audit, UI | False privacy assurance | Revocation/deletion/crypto-erasure/independent verification separated; scoped statuses | Comprehensive downstream proof usually impossible | Exact party/data/derivative/copy/exception scope; self-report label; independent evaluator/method; residual-copy warning | Universal proof often unavailable | Missing processor/derivative/backup means partial; self-report never displayed independent |

### Additional cross-cutting threats

| Threat | Required treatment | Evidence status |
|---|---|---|
| Archive/parser bombs, traversal, links, active content, polyglots, decoder exploits | No-network/no-secret sandbox; exact normalized member set; path/byte/count/ratio/depth/time limits; MIME/magic checks; inert viewers | Strong prose and shape/semantic cases; physical hostile-archive execution still required |
| SSRF and unsafe dereference | No fetch during parse; isolated allowlisted fetcher; block loopback/private/link-local/metadata targets; re-resolve redirects; cap bytes/time; no ambient credentials | Implementation evidence required |
| Secret leakage | Tokens, cookies, passwords, private keys, recovery codes excluded/quarantined from items, packages, models, embeddings, logs, events, analytics, and errors | Normative assertion exists; end-to-end deployed evidence required |
| Audit/digest correlation | No raw/free-text context or stable low-entropy digests in general telemetry; use opaque or purpose-scoped keyed references with separate keys/retention | Source rules exist; operational review required |
| Denial of service and proposal fatigue | Authenticated quotas, payload/graph bounds, semantic dedupe, idempotency, backpressure, privacy-safe 429, review-burden limits | Binding/source requirements; deployment evidence required |
| Supply-chain compromise | Pinned dependencies/schemas, signed build provenance where adopted, parser isolation, SBOM/vulnerability response, reproducible fixtures | Governance/implementation gate, not demonstrated by current source validation |

## 6.3 Missing controls and required normative requirements

The current core should retain these requirements; profiles or identified implementations must close the evidence gaps:

1. No request, receipt, signature, package, identifier, item, or review record authorizes by possession.
2. Every protected operation is authorized at operation time through the selected OAuth/GNAP/local profile.
3. Effective authorization is the most restrictive result on every typed dimension; absent, unknown, ambiguous, or incomparable values deny.
4. Complete declaration → request → receipt → package containment is required before content release.
5. Exactly one delivery recipient/client instance and every expected plaintext processor are explicitly bound to the decision chain.
6. Core packages always state `external_action_authority: "none"`; action gateways require fresh domain authorization.
7. Runtime and transfer packages remain different products; a transfer archive enters quarantine and has no runtime authority.
8. Non-public remote/offline packages require registered issuer-authenticity and recipient-confidentiality profiles; until they exist, the corresponding classes remain unavailable.
9. Packages contain no bearer URL, access/refresh token, cookie, private key, password, recovery code, or reusable capability.
10. Delegation defaults to none; every child needs new identity, authorization, receipt, package, key/aliases, actor chain, and strict attenuation.
11. All imported, derived, signed, and even accepted text remains untrusted data; no source proof skips quarantine or review.
12. Parsers run without ambient network/secrets and under quantitative limits; references use an isolated SSRF-hardened fetcher.
13. Unknown critical semantics fail; unknown noncritical material may be preserved inert for transfer but is not rendered, indexed, modeled, or disclosed by default.
14. Accepted state requires an accepting decision and exact result/scope commitment; nonaccepting outcomes cannot claim a result.
15. Proposal rights are bounded by operation, target/create selector, space, predicate/category, sensitivity, source attachment, time, receipt/client instance, and policy.
16. Core Personal is limited to competent-adult self-authorization of that person's own context; complex authority requires a profile.
17. Client declarations are versioned, expiring claims. Material processor/use/retention/training/deletion/offline/proposal/delegation change requires new review.
18. Revocation stops future provider-mediated operations but does not claim plaintext recall; deletion status always names reporter, scope, evidence, exceptions, and assurance.
19. Audit and telemetry exclude content, secrets, tokens, stable aliases, free-text purpose, and correlation-prone digests unless a narrowly authorized audit profile requires them.
20. Every public conformance assertion carries a status and evidence pointer; only an identified implementation's executed result may count as implementation pass/fail.

## 6.4 Consent and user-experience risks

A meaningful decision surface must show, in provider-controlled and accessible form:

- authenticated client/publisher and exact client instance;
- every processing recipient expected to receive plaintext;
- machine-coded purpose plus the exact human description;
- selected spaces/categories and context/evidence/artifact views;
- time limit, retention, training, advertising, logging/embedding, proposal, delegation, and offline choices;
- whether statements are client-declared, technically enforced, attested, audited, or unknown;
- what revocation stops and what it cannot recall;
- deletion capability and assurance limits; and
- source-dependent artifacts and material omissions/warnings.

Choices must be separate, unpreselected, default deny, and equally easy to decline. Client-supplied HTML/urgency must not control the trusted surface. Material changes require a new decision. High-risk decisions need explicit confirmation and cannot use fatigue, silence, or timeout as acceptance. WCAG 2.2 AA, screen-reader, keyboard, reflow, localization, cognitive-load, mobile, comprehension, and coercion-safety evidence are manual/external assurance—not derivable from JSON validity.

## 6.5 Third-party and organizational data

**Third-party data.** A person's archive can contain another person's private words, image, location, health, identity, or relationship information. Pseudonymization does not create disclosure authority and may leave highly identifying graph structure. The safe baseline excludes raw third-party sensitive content, minimizes aboutness/presence/source metadata, coarsens omission details, and defers multi-party thresholds, dispute, withdrawal, redaction, and downstream notice to a dedicated profile.

**Organizational data.** OCP normalization can make stolen work data more useful. A future profile needs controlling organization, custodian, source environment, classification/confidentiality, exportability, policy decision, retention, residency, DLP, audit, personal/proprietary separation, and role/authority rules. Managed or mixed data defaults to deny/quarantine in Core Personal. OCP can record and enforce an external decision; it cannot adjudicate ownership, contract, trade-secret status, or cross-border legality.

## 6.6 Cryptographic and key-management recommendations

- Use current TLS for transport. Sender-constrained OAuth tokens reduce stolen-token replay; they do not sign package meaning or stop plaintext copying.
- Define a **Remote Package Security Profile** with exact signed/protected view, issuer trust, one client-instance recipient, confidentiality, content/reference coverage, algorithm allowlist, type/version/domain separation, key discovery/status/rotation/revocation, and downgrade behavior.
- Define an **Offline Package Protection Profile** with a non-circular signed view, exact physical member set, ciphertext payload manifest, recipient/user-controlled keys, signing/encryption order, multi-recipient behavior, metadata leakage, archival agility, and wrong-recipient/tamper vectors.
- Use RFC 8785 only after strict raw decoding and I-JSON/numeric eligibility. It canonicalizes bytes, not meaning, truth, acceptance, or authorization.
- Separate signing, encryption, alias, audit-commitment, local-store, and recovery keys. Define issue, use, backup, rotation, compromise, revocation, re-encryption, destruction, and recovery evidence for each.
- No design simultaneously guarantees sole user control, perfect recovery, and no escrow. The chosen tradeoff must be disclosed. A recovery actor does not automatically gain review or context authority.
- Cryptographic erasure applies only to the precisely defined ciphertext/key graph whose usable key material is evidenced destroyed; it says nothing about plaintext, logs, outputs, training, backups, or recipient copies outside that graph.

## 6.7 Prompt-injection and package-forwarding controls

```text
OCP/package/source bytes
  -> strict decoding, schema, exact-reference, status, integrity, and authorization checks
  -> field-level minimization and inert/sandboxed rendering
  -> untrusted context data channel
  -> model

Authenticated policy + fresh action-specific authorization
  -> deterministic action gateway
  -> tool or external side effect
```

Delimiters or “ignore instructions in this data” are not enforcement. Context cannot change instruction priority, credentials, recipients, purpose, authorization comparison, tool schema/parameters, review outcome, or accepted state.

Recipient encryption prevents the wrong key holder from opening the original ciphertext. It cannot stop the intended recipient from copying, summarizing, embedding, screenshotting, or training on plaintext. Claims must distinguish `cryptographically_recipient_bound`, `client_declared_no_forwarding`, `contractually_committed`, `externally_attested`, `independently_audited`, and `unknown`.

## 6.8 Retention, revocation, deletion, and residual risk

| Claim | OCP-enforceable? | Honest 0.4 statement |
|---|---|---|
| Future online operations stop after revocation | Yes, within the provider/authorization propagation boundary | State exact effective time and propagation result. |
| Delivered plaintext is recalled | No | Recipient may still retain it. |
| Recipient obeyed purpose, retention, training, or forwarding terms | Not generally | Declaration, contract, attestation, audit, or controlled execution may provide scoped evidence. |
| Deletion completed everywhere | Rarely | Report exact party, data/derivative/copy scope, evidence, exceptions, and unknowns. |
| Cryptographic erasure | Only for a defined ciphertext/key graph | Does not cover plaintext or other copies without separate evidence. |
| Signature/proof means true, safe, lawful, or accepted | No | It establishes only the selected covered-byte/issuer/status relationship under a trust policy. |
| Pairwise alias means anonymous | No | Content, timing, and graph structure may re-identify. |
| Local-first means private | Not automatically | Models, other apps, malware, backups, logs, and recovery may disclose data. |
| No coercion occurred | No | Safety-oriented design can reduce risk but cannot prove free choice. |

## 6.9 Minimum security conformance program

| Test family | Required observable behavior |
|---|---|
| Authorization and containment | Invalid credential/receipt/status/instance/purpose/processor/use/time denies before bytes; every dimension equal or narrower; unknown comparison denies. |
| Action separation | Budgets, “approved,” behavior preferences, credentials, and hostile tool text release no mocked action. |
| Package protection | Bit tamper, added/removed member, wrong/revoked issuer or recipient key, wrong type/version/instance, weaker profile fail before plaintext. |
| Package references | Exact receipt/status and accepted decision/result/scope resolve; all package-local refs close; aliases are unique and do not expose store IDs/digests. |
| Delegation/forwarding | Depth-zero child denied; allowed child uses new authorization/receipt/package/key/aliases; every dimension attenuates. |
| Offline | Absent choice is prohibited; wrong time/key/status fails; UI admits that revocation does not recall prior plaintext. |
| Import/injection | Instructions in JSON, filenames, HTML, code, metadata, OCR, transcript, image/audio/PDF, archive, and derived summary cause zero policy/tool/network/write effect. |
| Parser/SSRF/secrets | Traversal, links, collisions, bombs, recursion, polyglots, unsafe codecs, private-network URLs, and secrets fail/quarantine without escape or egress. |
| Authority/privacy | Third-party, managed organization, joint, child/guardian, and coercion-sensitive fixtures fail baseline without the required profile. |
| Consent/accessibility | Trusted display matches exact declaration/request; no preselection/client HTML/urgency; material change re-prompts; keyboard/screen-reader/reflow evidence retained. |
| State/concurrency | Every legal transition and every unlisted pair tested; stale writer conflicts; idempotent retry stable; no partial mutation. |
| Revocation/deletion | Future online operations fail; incomplete scope is partial; self-report never shown independent; limited key destruction never shown universal. |
| Audit/DoS | No content/secrets/tokens/stable digest in general logs; quotas, dedupe, backpressure, privacy-safe errors, and review-burden limits work. |
| Evidence accounting | Every assertion result resolves to same-generation evidence and named system; aggregate implementation pass counts only executed identified implementations. |

The current **27 / 23 / 45 / 243 / 29 / 107** local results are useful source evidence for this program. They are not completion of the program.

## 6.10 Required red-team questions — all 35 answered

1. **Is OCP really a protocol?**  
   **Yes, now as a protocol family.** The nine-record core defines stateful request, receipt, package, proposal, and decision semantics; bindings define operations and envelopes; registries define transitions/errors/events; conformance defines actor behavior. OCP is not merely a data format, but the core should remain transport-neutral.

2. **Is its core too large?**  
   **No, if the present boundary holds.** Nine records are a reasonable minimum for source/acceptance and disclosure/write-back governance. The core becomes too large if profile sketches, artifacts, conversations, credentials, delegation, organizations, HIB/continuity state, or cryptography are relabeled core.

3. **Is its core too small to be useful?**  
   **No.** A space, source, typed item, declaration, request, receipt, package, proposal, and decision are sufficient for a compelling two-provider demonstration. Rich domain ontologies and artifact bytes are not necessary for the first useful exchange.

4. **Is the “canonical context” concept safe and understandable?**  
   **Not under that name.** OCP 0.4 correctly uses **accepted context**: an exact revision approved for a recorded scope. It is not truth, completeness, identity, permanence, legality, or universal agreement. “Canonical” is reserved for deterministic representation.

5. **Does “the person is the final authority” break down in multi-party settings?**  
   **Yes.** A person cannot unilaterally control another person's message, an employer's confidential record, a child's evolving rights, or a joint artifact. The baseline is one competent adult self-authorizing context about themself; other cases require profile-specific authority sets, thresholds, rights, and safety rules.

6. **Does OCP create a new centralized privacy risk?**  
   **Potentially.** A normalized hosted context store is a high-value aggregation target. Storage neutrality, scoped spaces, minimization, pairwise identifiers, key separation, local/self-hosted options, and narrow packages reduce risk but cannot remove the concentration risk.

7. **Could OCP become an attractive surveillance or identity-theft target?**  
   **Yes.** The same normalized meaning that improves continuity improves profiling. Metadata, review history, recipient relationships, and audit data are sensitive; providers must avoid dossier defaults and cross-space/global identifier exposure.

8. **Could clients pressure users into granting excessive context?**  
   **Yes.** Exact schemas cannot prevent dark patterns, economic coercion, or fatigue. Trusted provider-controlled UI, unbundled default-deny choices, equivalent decline, prior-denial/cooldown handling, material-change re-review, accessibility, and comprehension testing are required.

9. **Could a context package become an untrusted prompt-injection payload?**  
   **Yes, even when signed and accepted.** Every entry and rendering stays untrusted data. Application code—not a model instruction—must enforce channel isolation, inert rendering, tool/policy separation, and fresh action authorization.

10. **Does the protocol rely too heavily on OAuth?**  
    **No in the 0.4 architecture.** OAuth/RAR is one remote binding. Local-first deployments can use OS brokers, app-bound IPC, keys, and user presence while preserving the same decision semantics. OCP relies on authorization, not necessarily an OAuth server.

11. **Is the proposed context grant duplicating OAuth authorization?**  
    **No, after the `grant_receipt` correction.** It records the effective OCP decision and links to the actual authorization; it is non-secret and non-authorizing. If possession of it ever grants access, OCP would be duplicating or weakening the authorization layer.

12. **Are the request, grant, and package objects sufficiently different?**  
    **Yes structurally and semantically in 0.4.** The request is untrusted desired access, the receipt is an attenuated decision snapshot plus live status, and the package is immutable minimized data. Exact references and typed containment bind—but do not collapse—them.

13. **Are context scopes realistically interoperable without an ontology?**  
    **Only within bounded vocabularies/profiles.** Core uses URI purpose/predicate identifiers, typed selectors/views, and registered partial orders. Unknown or incomparable semantics fail closed. OCP should not create a universal human ontology.

14. **Is natural-language context portable enough for models but deterministic enough for software?**  
    **Not by itself.** Natural language is a useful derived rendering, but core records require structured JSON, typed values, exact references, and rendering lineage. Text-only exchange cannot claim semantic round trip.

15. **Should structured JSON always be required?**  
    **For Core Producer/Consumer and round-trip conformance, yes.** Binary artifacts may be referenced with media type/size/digest under profiles, and human-readable renderings may accompany entries, but neither replaces the structured core representation.

16. **Can the object model round-trip without semantic loss?**  
    **The model can represent explicit loss, but lossless round trip is not yet independently proven.** The PAM map shows eight of nine core records lack even the strongest source-record analogue; all nine require explicit loss accounting, and omitted OCP semantics require a sidecar or declared loss. Two independent A → B → A implementations must compare accepted decisions/scopes, sources, typed values, unknowns, identities, and losses.

17. **Does the protocol adequately handle multiple contradictory providers?**  
    **At the data-model level, yes.** Provenance, epistemic basis, disputes, and multiple items can coexist; last-write-wins and confidence-only resolution are forbidden. Real conflict-review UX and cross-provider behavior remain untested.

18. **Does it distinguish user intent from provider interpretation?**  
    **Yes—this is a core strength.** Epistemic basis and review status are independent; import cannot create `subject_confirmed` or `accepted`; exact review evidence is required.

19. **Are artifacts too central for the initial core?**  
    **No in 0.4 because they are outside the nine-record core.** Core can reference evidence/artifacts under separate views. Content storage, active formats, chunking, rights, C2PA, lineage, and preservation remain profile work.

20. **Is artifact storage being confused with context portability?**  
    **The current architecture avoids that confusion.** It records source dependence, references, custody/verification claims, and losses without requiring every provider to become a blob store. Profile wording must continue to avoid “preserved forever.”

21. **Can a client prove that it honored retention and deletion commitments?**  
    **Usually not through OCP alone.** It can issue a signed declaration and scoped status report; stronger evidence requires technical isolation, audit, attestation, independent evaluation, contract, or regulator. The assurance source must be labeled.

22. **Does revocation offer meaningful protection after disclosure?**  
    **Yes, but narrowly.** It stops future provider-mediated package issuance, reads, proposals, and synchronization and can invalidate live credentials/references. It cannot retract decrypted plaintext, so that limit must be adjacent to every revocation claim.

23. **Can third-party privacy be protected in social and relationship context?**  
    **Only conservatively.** Baseline excludes raw third-party sensitive content and protects presence/relationship metadata. A later profile needs per-item authority, thresholds, minimization, dispute, withdrawal, redaction, and downstream notice. Pseudonymization alone is insufficient.

24. **Can organizational context be portable without enabling data exfiltration?**  
    **Potentially, but not under Core Personal.** A dedicated organization profile must encode custodian, source environment, classification, exportability, policy decision, role authority, DLP, retention, residency, and audit. Access to source data is not permission to export it.

25. **Are local-first and self-hosted implementations realistically possible?**  
    **Yes.** The semantic chain can use an OS broker, authenticated Unix-domain socket, code-signing identity, secure pairing, client-instance key, and user presence. Loopback/same-user/device-unlock are not blanket authorization. No real local implementation has yet been evaluated.

26. **Are the schemas complete enough to build?**  
    **Yes for a core prototype and current bindings; no for broad production claims.** Twenty-seven schemas and 23 positive fixtures form a substantial source contract. Security profiles, strict raw-input handling, and complete profile documents remain incomplete.

27. **Are the endpoints sufficient for a real implementation?**  
    **Sufficient for a prototype, not proven for production.** OpenAPI covers discovery, declaration registration, request create/read/status, receipt/status, package create/read/entry dereference, proposal/decision, transfer manifest, and events with RFC 9457 errors, idempotency, and preconditions. Real async scale, rate limits, OAuth/local integration, caching, and failure behavior need implementation tests.

28. **Does the conformance model test actual behavior?**  
    **It specifies actual behavior but currently proves only source/reference behavior.** The ledger honestly reports zero implementation passes/failures. Parser isolation, network/tool side effects, authorization, cryptography, consent, deletion, and recipient conduct remain unexecuted, manual, unavailable, or externally assured.

29. **Is the standards landscape already solving enough of this that OCP should be smaller?**  
    **Yes, and 0.4 has mostly made that reduction.** PAM, OAuth, OIDC, MCP/A2A, Solid, PROV, C2PA, VC, DPV, JSON Schema/JCS, CloudEvents, and OpenTelemetry own horizontal layers. OCP should keep only the governed-context vertical and publish exact mappings.

30. **What is the strongest argument against OCP?**  
    It may create a richly normalized privacy target and policy-heavy integration burden while duplicating enough PAM/authorization behavior that providers prefer simpler memory formats and product-specific consent, leaving no interoperable ecosystem.

31. **What would cause OCP to fail even if the technology works?**  
    Weak provider incentives, confusing or burdensome consent, one damaging breach, no high-value first-use case, too many profiles, incompatible vocabularies, perceived KnowOnce control, unresolved IP/governance, or inability to recruit two independent implementations.

32. **What is the smallest compelling OCP interoperability demonstration?**  
    Two independent providers and two clients exchange one adult's accepted derived preference: exact declaration and partial request decision; short-lived one-instance package; one accepted and one rejected proposal; expiry/revocation failure; then a loss-accounted transfer and re-export whose accepted-state history and unknown data compare semantically.

33. **What should be removed before public publication?**  
    Remove production/security/interoperability implications, internal workstation paths and scratch/dependency artifacts, any claim that schema sketches are complete profiles, any suggestion that current crypto is executable, and historical material presented as current authority. Keep the bounded profile sketches only with unmistakable draft labels and evidence limits.

34. **What is missing that could become expensive to add after 1.0?**  
    Durable namespaces and extension governance; exact identity/alias domains; multi-party authority model; immutable decision/history semantics; profile composition/downgrade rules; package-security and key lifecycle; strict raw representation; transfer/unknown/loss rules; conformance evidence semantics; and neutral IP/security/governance processes.

35. **Which three design decisions require implementation experiments before standardization?**  
    **(1)** exact declaration/request/receipt/package containment across both OAuth/RAR and a local broker; **(2)** hostile import/transfer plus PAM/OCP sidecar and A → B → A loss-aware round trip across two stacks; **(3)** recipient-bound remote/offline package protection and an accessible consent/revocation/deletion experience tested against wrong-recipient, downgrade, forwarding, comprehension, and coercion scenarios.

---

# Deliverable 7 — Language and structure review

## 7.1 Editorial verdict

OCP 0.4 is substantially clearer than the original draft. It explains the user problem before the formal model, names a small core, assigns responsibilities to actors, states failure behavior, puts exact schemas/examples in the same source, and repeatedly distinguishes design requirements from evidence. The document is long because it is standalone and embeds all generated examples and schemas, but its conceptual order is defensible.

The strongest editorial achievement is precision around limits: accepted is not true; receipt is not authority; context is not instruction; delivery is not deletion; a URL is not preservation; a profile sketch is not full profile conformance; local fixtures are not implementation evidence. Those distinctions should remain visible beside the feature, not only in front matter.

The remaining risk is not vague prose so much as **maturity slippage**: readers may still overread “project-authoritative,” “verified,” “independently assessed,” “profile,” “protected,” or a green aggregate count. Each such term needs its qualifier, scope, responsible evaluator, and evidence class every time it matters.

## 7.2 Terminology problems and current resolution

| Earlier or ambiguous term | Problem | Current 0.4 preferred term / rule |
|---|---|---|
| canonical context / canonical status | Implies truth, completeness, or one digital identity; collides with canonical JSON | **accepted context** and **review status**; “canonical” only for deterministic representation/bytes |
| context grant | Sounds like OAuth grant/token or bearer capability | **grant receipt**: non-secret record of effective OCP decision, never authority by possession |
| audience | Collapses service, instance, processor, model provider, and child recipient | Exactly one **delivery recipient/client instance** plus approved **processing recipients**; delegation is separate |
| `source_provider` | Collapses origin, adapter/importer, and record emitter | **source authority**, **runtime source**, and `created_by`, each distinct |
| `assertion_kind` | Blends claim taxonomy and epistemic origin | **epistemic basis**: subject asserted/confirmed, provider observed/inferred/interpreted, third-party asserted, credential-derived, imported-unclassified |
| `kind: instruction` | Encourages instruction laundering into model control channels | Non-control **category: behavior_preference** with `instruction_treatment: untrusted_data` |
| person / user / subject / steward | Lets aboutness imply identity or authority | **subject**, **authenticated principal**, **authorizer**, **reviewer/steward**, each independently established |
| provider | Could mean OCP host, source system, model operator, authorization server, or destination | Qualify **context**, **source**, **model**, **authorization**, and **destination** provider |
| client | Could mean publisher, OAuth client, application, process, agent, or model | Qualify **client application**, **publisher**, **client instance**, **workload/agent**, and **model** |
| purpose | Free text looks enforceable | Exact `{code, description}` review object; equality in core, registered comparison in profiles; post-disclosure conduct still qualified |
| scope | One word hides incompatible dimensions | Use **selectors, views, purpose, recipient, processors, time, uses, retention, proposal rights, delegation, offline use** |
| source | Could mean actor, URL, file, or OCP record | **source record**, **source authority**, **source object**, **source locator**; a locator is not identity or preservation |
| artifact | Mixes descriptor, bytes, URL, copy, and lineage | **artifact descriptor**, **content**, **source locator**, **managed copy**, **lineage event** under a profile |
| preserved / mirrored | Implies permanence or current sync | State custody, retrievability, byte digest, verification time, source dependence, and sync state explicitly |
| verified | Hides what, by whom, and under which trust decision | Qualify **digest matched**, **signature verified**, **credential proof verified**, **provider reported**, or **independently verified for stated scope** |
| transfer / export / import | Blends archive creation, delivery, parsing, acceptance, and migration | **export archive**, **transfer workflow**, **destination import quarantine**, **validation with losses**, **round-trip comparison** |
| revocation / deletion / erasure | Suggests recall or universal proof | **future-access revocation**, **deletion request/status**, **reported completion**, **cryptographic erasure**, **independent verification** |
| profile / binding / mapping / conformance | Optional mechanisms were previously grouped together | **profile** adds bounded semantics; **binding** defines transport/serialization; **mapping** converts with loss; **conformance** is actor behavior plus evidence |
| project-authoritative | Can be mistaken for standards adoption | Current repository/editorial source until superseded; explicitly not SDO adoption, security certification, or interoperability evidence |

## 7.3 Confusing or potentially overread passages

| Minimal current phrase/concept | Risk | Required reading or rewrite discipline |
|---|---|---|
| “current project-authoritative working draft” | Readers may infer adopted standard | Always pair with “until superseded” and the explicit non-standard/non-production status. |
| “accepted context” | Readers may still hear truth or identity | Keep the exact definition: this revision was approved for this accepted scope; no more. |
| “independently assessed” client declaration | Shape validation may be mistaken for assessor trust | State that the provider must resolve and recompute the exact active evidence snapshot, bind its authority to the evaluator, and obtain an affirmative current trusted scope evaluation; schema validity alone is insufficient. |
| “signature verified” / “credential proof verified” | A successful proof may become truth or authority | Name covered digest, profile, issuer, verifier, status result/time, trust decision, and limitations; preserve untrusted treatment and review state. |
| “recipient-bound” | Can imply forwarding prevention | Say what is bound cryptographically and state that the intended recipient can copy plaintext. |
| “protected non-public package” | Current release has no executable protection profile | Make conformance conditional on a registered executed profile; current SEC/XFR crypto assertions remain unavailable. |
| “profile” for continuity observation or HIB | Two schema sketches may appear complete | Continue calling them `0.1-draft` schema sketches until Section 33.2 contracts and fixture suites exist. |
| “observe only” continuity/HIB state | Applications may still use a signal as policy | State structurally that it cannot authorize, rank, suppress, execute, or silently mutate accepted context. |
| “purpose-bound” | A field may be mistaken for enforcement after disclosure | Distinguish provider-mediated enforcement from client declaration, contract, attestation, or audit after plaintext delivery. |
| “minimized” | “Smallest useful” is not deterministic | Tie minimization to approved selectors/views, purpose, profile rules, and explicit omission handling. |
| “available” / “delivered” package | Can sound like used, acknowledged, retained, or deleted | Keep lifecycle meanings narrow and separate from recipient conduct. |
| “validated transfer” | Can sound lossless or accepted | Preserve `validated_with_exceptions`, per-entry losses, quarantine, and a separate accepted-state review. |

## 7.4 Jargon and required plain-language explanations

Before formal use, explain:

- **exact snapshot reference:** record ID, revision, schema, and digest that identify immutable bytes/semantics;
- **live-status reference:** authorized endpoint for current state, not a substitute for the historical snapshot;
- **pairwise identifier:** a different identifier for the same entity in different recipient contexts to reduce easy joining;
- **package-local alias:** an opaque name valid only inside one package;
- **sender-constrained token:** a token usable only with a bound key, reducing stolen-token replay but not plaintext copying;
- **canonicalization:** deterministic JSON serialization for hashing, not a truth decision;
- **typed containment:** proof that each approved/delivered dimension is equal to or narrower than the prior decision;
- **critical extension:** semantics a receiver must understand or reject;
- **round trip:** export at A, import/re-export at B, and semantic comparison with every loss declared;
- **quarantine:** retained content barred from accepted state, runtime disclosure, and control channels pending checks/review;
- **attestation/assurance:** a statement plus issuer, method, scope, and evidence—not necessarily enforcement; and
- **processor versus delegate:** a processor receives approved plaintext for the delivery recipient but gains no independent OCP rights; a delegate is a separately authorized child principal.

Expand RAR, DPoP, JCS, I-JSON, PROV, C2PA, DPV, BOLA, CSPRNG, PRF, SSRF, DLP, and OTel once before abbreviation in explanatory text.

## 7.5 Normative-language review

The 0.4 normative style generally meets the correct test: identify actor, condition, exact behavior, failure, owning core/profile, and assertion. Retain these editorial rules:

1. A `MUST` about a package must say whether the producer must include a field, the consumer must reject its absence, or both.
2. “Minimum useful,” “meaningful,” “appropriate,” and “where risk requires” need a registered comparator/profile or must remain informative.
3. A requirement about downstream purpose, retention, training, deletion, accessibility, coercion, or legal authority must name the assurance/evaluation mechanism; it cannot appear as a machine-tested guarantee by implication.
4. Security requirements conditioned on a registered profile must not imply the unavailable profile exists in this release.
5. A profile `MUST` claim is not operative until the profile has its own version, applicability, authority/privacy/threat model, transitions/errors, unknown/downgrade behavior, and conformance evidence.
6. Strict raw JSON `MUST reject` rules remain valid normative requirements, but the current object-level JavaScript harness must not be described as proof of every raw-input facet.
7. Examples are informative instances of normative schemas. Their validity is required for editorial credibility but does not make example-specific values mandatory.
8. Unknown critical behavior needs an explicit reject code; unknown noncritical behavior needs explicit preserve/quarantine/no-render/no-disclose rules.

## 7.6 Examples and explanatory gaps

All 23 current positive fixtures validate, and all 45 current negative fixtures reject at their declared rule. The examples now clarify exact references, recipient/processor separation, typed entries, accepted-decision linkage, bounded proposals, source verification evidence, offline member sets, transfer losses, adapter determinism over declared inputs, and the no-action boundary.

Examples still cannot clarify these behaviors without executable systems:

- real OAuth/RAR and local-broker authorization;
- recipient encryption/signature/key rotation/downgrade;
- strict raw-byte JSON and cross-language JCS;
- parser/SSRF/media/prompt/tool containment;
- two-provider transfer and PAM sidecar round trip;
- accessible decision/revocation/deletion comprehension; and
- full conversation/artifact/erasure/continuity/HIB profile semantics.

Those gaps should appear as named prototypes and assertion statuses, not as additional illustrative JSON that could be mistaken for proof.

## 7.7 Proposed document structure

The current 45-section structure already follows the required plain-English-to-formal order. Preserve this grouping:

1. **Status and orientation:** cover/status, plain-English sentence/paragraph/example/diagram, abstract, problem, goals, non-goals, principles, terminology.
2. **Architecture:** roles, deployment models, core/profile split, trust boundaries, data/control channels, happy/failure flow, effective authorization.
3. **Core object model:** envelope and nine records, normative JSON/schema/identifier/value/provenance/integrity/extension rules.
4. **Core lifecycles:** request, receipt, package, proposal/review, accepted context, evidence/interpretation.
5. **Domain-profile placement:** conversation/message and artifact/lineage rules, clearly marked draft/profile scope.
6. **Movement and continuity:** import/adapter, export/round trip, transfer, revocation/erasure.
7. **Security, privacy, and authority:** threat model, cryptography/keys, consent, third-party, organizational, multi-party boundaries.
8. **Bindings:** HTTP/discovery/OpenAPI/errors/events; offline archive format.
9. **Interoperability:** adjacent-standard mappings with PAM first.
10. **Evolution mechanics:** versioning, extensions, profiles, registries, errors.
11. **Conformance:** actor classes, assertion registry/evidence statuses, reference implementation and production gates.
12. **Governance and future:** neutrality, IP/change/security/namespace policy, 2026–2031 horizon, roadmap, open questions.
13. **Generated appendices:** exact positive examples, exact schemas, references, glossary.

Keep generated examples/schemas synchronized from machine files. In a shorter implementer edition, link to machine files instead of embedding all 27 schemas, but retain the standalone publication edition for archival review.

## 7.8 Document-production recommendations

- Keep the restrained hierarchy, short paragraphs, tables, and real monospace code blocks.
- Repeat draft/non-production status in cover, footer, conformance, and artifact metadata.
- Give diagrams/tables stable captions and accessible descriptions; validate heading order and table headers.
- Keep citations version-pinned and distinguish standards, drafts, community reports, law, and independent projects.
- Generate counts and appendices from one source of truth; fail publication when human surfaces drift.
- Exclude dependency directories, temporary renders, absolute workstation paths, and historical reports that can be mistaken for current release authority.
- Publish historical rationale only under a clear non-normative/historical label; current review summaries must describe current 0.4 state.

---

# Deliverable 8 — Revision plan

## 8.1 Version decision

The correct current label is **OCP 0.4 — Consolidated Editor's Working Draft**, with semantic wire version `0.4`. The move from the 0.2 review architecture is wire-breaking: exact snapshot/live references, delivery-recipient/processor modeling, source/runtime roles, category/epistemic vocabulary, typed package entries, bounded proposal targets/rights, accepted-result commitments, offline manifest construction, transfer classification, create-input schemas, and evidence accounting all changed. A patch label would hide incompatibility.

The maturity suffix remains essential. `0.4` is a project version, not “30% complete,” standards adoption, interoperability-candidate status, or production readiness. The separate 0.9 document is an architectural proposal source, not a predecessor wire version.

## 8.2 Retained concepts

| Retained concept | Current 0.4 treatment |
|---|---|
| Provider-neutral, storage-neutral portability | No KnowOnce account, service, API, identifier, storage, terms, or approval is required. |
| Evidence → provider interpretation → accepted context | Retained as independent epistemic and review axes with exact source/decision relationships. |
| Request → authorization → receipt → package → proposal → review → revoke/export | Retained with explicit external authorization, typed attenuation, live status, and immutable resources. |
| No silent accepted-state writes | Strengthened through bounded proposals, exact targets, immutable review decision, and accepted-result commitment. |
| Context/evidence/artifact view separation | Retained in request/receipt/package and typed entry branches. |
| Provenance is not preservation | Retained through source authority/runtime source, availability/custody, digest/verification time, and profile boundaries. |
| Revocation is not erasure | Retained with separate future-access, report, cryptographic-erasure, and independent-verification semantics. |
| Context is not action authority | Structural `external_action_authority: "none"`, untrusted markers, and control-plane separation. |
| Local-first and self-hosted operation | Retained through binding-neutral semantics and a local broker model rather than mandatory OAuth. |
| Round-trip honesty | Retained through exact references, opaque unknown preservation, per-entry results, and mandatory loss reporting. |

## 8.3 Revised concepts

| Prior concept | Current 0.4 revision |
|---|---|
| Broad portable memory protocol | Narrow governed-context protocol family with mappings to PAM and other standards. |
| Canonical context | Scoped accepted context; canonical only for representation. |
| One person as universal final authority | Core Personal self-authorization; every other authority domain requires profile-specific rules. |
| One common envelope | Persistent record family plus native HTTP/problem/event/offline/transfer envelopes. |
| Context claim/instruction | One `context_item` with non-control category, typed statement, epistemic basis, review, provenance, validity, and lifecycle. |
| Evidence/provider field | `source_record` with source authority, runtime source, emitter, verification evidence, availability, and untrusted treatment. |
| Context grant | Non-secret `grant_receipt` plus real operation-time authorization. |
| Audience array | One delivery service/client instance and exact approved processing-recipient set. |
| URI reference | Exact immutable `snapshotRef` or separate authorized `liveStatusRef`, selected by semantics. |
| Arbitrary package JSON | Closed discriminated entry branches, exact schema/media/digest, one carrier, package-local references, and inert renderings. |
| Binary proposal permission | Bounded operation/selector/sensitivity/source rights with exact target and live grant status. |
| Nested/mutable review | Separate immutable `review_decision`; accepting outcomes alone commit to exact result/scope. |
| Transfer as ambiguous core/profile | Core export invariants plus a Transfer Binding manifest/lifecycle. |
| Green test aggregate | Per-assertion status/evidence; zero implementation passes unless a named system actually executes. |

## 8.4 Removed or merged concepts

| Removed / merged | Current disposition |
|---|---|
| Second “continuity” core and second package format | Rejected; observe-only concepts may profile the governed-context core. |
| Artifact, Conversation, Message, Credential, Erasure, Stewardship, Delegation, Organization as core records | Removed from nine-record core; profile or future-profile work. |
| Separate claim, goal, decision, instruction, note record families | Merged into generic `context_item` categories or Work Context Profile. |
| Generic action and context event records | Historical action becomes lineage/activity profile; notifications use CloudEvents. |
| Bearer grant or token-response-as-record | Rejected; receipt never authorizes by possession. |
| Universal RAR/DPoP requirement | Rejected; useful only in selected remote bindings/profiles. |
| Destructive “sanitization” of imported content | Rejected; preserve exact raw evidence and create separately identified inert derivatives. |
| Self-invented “AES with public key” rule | Rejected; complete reviewed hybrid protection profile and vectors required. |
| Universal CloudEvents audit format | Rejected; events are optional notifications, not state/audit authority. |
| Text-only core round-trip | Removed; text is a derived rendering linked to structured entries. |

## 8.5 Moved concepts and deferred profiles

| Concept | Placement | Evidence required to advance |
|---|---|---|
| Remote package authenticity/confidentiality | Remote Package Security Profile | Two independent implementations; issuer/recipient/key/downgrade/tamper vectors; adversarial review |
| Offline package protection | Offline Package Protection Profile | Non-circular signed/encrypted construction; archive/key/wrong-recipient/downgrade vectors |
| Conversation/message | Domain profile | Branch/role/attachment/redaction/selection round trip across two stacks |
| Artifact/lineage/preservation | Domain profile | Hostile media, rights/custody, C2PA, read/digest, version/migration, and transfer evidence |
| Credential/selective disclosure | Evidence profile | VC/SD-JWT/native mapping, verifier/status/linkability, and no-action tests |
| Organization/household/joint context | Authority profiles | Roles, custody, thresholds, disagreement, withdrawal, DLP, safety/legal/accessibility review |
| Minors/guardians/incapacity/inheritance | Vulnerable-person profiles | Rights transition, assent, partitions, best-interest, safety and jurisdiction evidence |
| Agent delegation | Delegation Profile | Child authorization, actor chain, key/package renewal, strict attenuation, revocation prototype |
| Live sync/multi-writer/CRDT | Sync Profile | Real offline multi-writer cases showing snapshots/revisions/ETags insufficient |
| Continuity Observation and HIB | Optional `0.1-draft` observe-only profile work | Full Section 33.2 contract; privacy/retention/correction/deletion; hostile and round-trip fixtures |
| Domain ontologies | Separate profiles | Two producers/consumers and public vocabulary governance for each domain |
| Post-quantum algorithms | Future security profiles | Mature selected algorithms, key migration, archival tests, and interoperability need |

## 8.6 New 0.4 concepts

- scoped normative-source authority and current project-authoritative status;
- exact `snapshotRef` versus `liveStatusRef`;
- one delivery recipient/client instance plus an order-independent processing-recipient set;
- source authority, runtime source, and emitter separation;
- `epistemic_basis` independent from review state;
- descriptive `category` and `behavior_preference` instead of authoritative instruction kind;
- package-local subject/space/item/source/decision aliases and closure rules;
- typed layer/disclosure package entries with exactly one content carrier;
- exact purpose object comparison and complete declaration/request/receipt/package containment;
- bounded proposal rights and exact target snapshot semantics;
- non-circular accepted-result projection including accepted scope;
- evidence-backed source verification and independent-assessor identity checks;
- provider-authored create-state exclusion in dedicated HTTP input schemas;
- non-circular offline payload/security member sets and exact physical archive equality;
- exact provider-adapter raw bytes, mapping projection, semantic digest, and loss outcomes;
- per-assertion evidence status with no implicit implementation pass; and
- experimental exact PAM v1.0 mapping across all nine records.

## 8.7 Changed schemas

The current 27-schema inventory is:

| Group | Count | Current files / purpose |
|---|---:|---|
| Core | 10 | shared `common` vocabulary plus nine concrete core record schemas |
| HTTP binding | 7 | request-create, proposal-create, review-decision-create, transfer-manifest-create, discovery, RFC 9457 problem, exact event notification |
| Offline/transfer bindings | 2 | offline package manifest and transfer manifest |
| Profile sketches | 7 | conversation, message, artifact descriptor, lineage event, erasure status, continuity observation, HIB |
| Conformance | 1 | provider-adapter fixture |
| **Total** | **27** | All compile in the local reference harness; completeness/maturity varies by group. |

Every core shape is closed and uses explicit extensions. Security-significant references use exact snapshots or live status according to their job. Schema validity remains only the first layer; cross-object, lifecycle, containment, digest, mapping, and authority rules require semantic validation.

## 8.8 Changed HTTP operations

The OpenAPI 3.1 binding currently defines:

| Method and path | Operation | Key 0.4 behavior |
|---|---|---|
| `GET /.well-known/ocp-configuration` | Discovery | OCP versions, schemas, bindings, profiles, authorization links; does not replace OAuth resource metadata. |
| `POST /client-declarations` | Register declaration | Versioned declaration; assurance remains evidence-qualified. |
| `POST /context-requests` | Create request | Dedicated create input; server assigns submitted state/envelope; idempotent. |
| `GET /context-requests/{request_id}` | Read request | Object-level authorized, ETag-aware retrieval. |
| `GET /context-requests/{request_id}/status` | Read live request state | Separates immutable snapshot from current lifecycle. |
| `GET /grant-receipts/{grant_id}` | Read receipt | Receipt is non-secret/non-authorizing; access still protected. |
| `GET /grant-receipts/{grant_id}/status` | Read live receipt state | Fresh authorized status for package/proposal checks. |
| `POST /context-packages` | Build package | Operation-time authorization and complete containment before emission. |
| `GET /context-packages/{package_id}` | Read package | Exact recipient/client-instance checks and no-store/privacy behavior as profiled. |
| `GET /context-packages/{package_id}/status` | Read live package state | Typed state-of-record response with cache and precondition behavior. |
| `GET /context-packages/{package_id}/entries/{entry_id}` | Dereference entry | Package-local alias and full object-level authorization; no existence leak. |
| `POST /update-proposals` | Submit proposal | Dedicated create input, bounded rights, exact/live grant checks, server-assigned submitted state. |
| `GET /update-proposals/{proposal_id}/status` | Read proposal state | Typed terminal/pre-decision state and exact latest-decision linkage. |
| `POST /update-proposals/{proposal_id}/decisions` | Decide proposal | Reviewer authority, preconditions, immutable decision/result behavior. |
| `POST /transfer-manifests` | Create transfer manifest | Binding-level per-entry outcomes/losses; does not accept imported context. |
| `GET /transfer-manifests/{transfer_id}` | Read transfer manifest | Full persistent manifest, per-entry outcomes, losses, and exceptions. |
| `GET /transfer-manifests/{transfer_id}/status` | Read transfer state | Typed state-of-record lifecycle response. |
| `GET /events` | List optional events | CloudEvents batch/reference-first notifications; events are not state or audit authority. |

RFC 9457 problems, stable OCP codes, correlation IDs, `If-Match`/preconditions, idempotency, cursor pagination, discovery-advertised quantitative limits, Retry-After behavior, and typed package/transfer status reads are part of the binding. Deployment-specific limit values, job scheduling, cache infrastructure, and authorization-service behavior remain advertised implementation choices requiring evidence.

## 8.9 Changed terminology

Adopt globally and preserve in all future profiles/mappings:

- canonical context → accepted context;
- canonical status → review status plus separate lifecycle/validity/disclosure axes;
- context grant → grant receipt;
- audience → delivery recipient/client instance plus processing recipients;
- source provider → source authority plus runtime source and emitter;
- assertion kind → epistemic basis;
- instruction kind → behavior preference / descriptive category, always untrusted data;
- scope → typed selectors, views, purpose, recipient, time, uses, retention, proposal/delegation/offline dimensions;
- preserved artifact → managed/independent copy with retrievability, digest, verification time, and source-dependence statement;
- deletion complete → reporter-complete for exact scope; independent verification separately qualified;
- profile → bounded domain/security semantics; binding/mapping/conformance remain separate terms.

## 8.10 Unresolved decisions

| Decision | Safe current choice | Evidence required |
|---|---|---|
| Durable namespaces and governance | `https://opencontinuity.org` selected for working-draft identifiers; no stable compatibility mark or completed archival/redirect governance | Neutral charter, archival/redirect policy, contribution/IP/trademark/security/deprecation process |
| Specification/code licensing and patents | Proposed CC BY 4.0 / Apache-2.0 split remains unadopted | Counsel/community approval and actual license/contribution/patent files |
| Remote/offline protection | Mark corresponding conformance unavailable | Complete profiles, vectors, two implementations, adversarial review, key lifecycle |
| Pairwise alias construction | Require unlinkability/unpredictability outcome | CSPRNG versus keyed-PRF choice, domain/rotation/recovery/merge tests |
| Purpose/profile vocabularies | Exact core object; unknown fails | Two authorization implementations and DPV/domain mapping experience |
| OCP/PAM relationship | Exact experimental mapping; no broad memory claim | Machine sidecar/loss fixtures and two independent bidirectional adapters |
| Complex authority | Unsupported in Core Personal | Domain legal/safety/rights/threshold/accessibility evidence |
| Delegation | Exactly none | Child authorization/attenuation/revocation prototype |
| Offline runtime | Prohibited | Recipient protection, status/staleness UX, hardware/online enforcement evaluation |
| Profile promotion | Keep seven files as draft sketches | Complete Section 33.2 contracts and independent fixture/round-trip evidence |
| Public maturity | Working draft only | Two independent core implementations, hostile tests, security/human evidence, and governance |

## 8.11 Prioritized execution sequence

### Phase 1 — Freeze and publish the source honestly

1. Keep one authoritative 0.4 source tree and generated appendices.
2. Publish manifest/checksums and deterministic package evidence.
3. Exclude dependency/scratch/internal-path artifacts and label historical rationale.
4. Preserve zero implementation-pass and unavailable-profile statements.

### Phase 2 — Prove core authorization and package interoperation

1. Implement the same exact comparator in two independent stacks.
2. Exercise OAuth/RAR and local broker bindings.
3. Exchange declaration, partial request decision, receipt/status, package/entry, proposal/decision, expiry, and revocation.
4. Publish every widening/substitution/replay result with zero-byte/zero-side-effect evidence.

### Phase 3 — Prove hostile import and round trip

1. Add strict raw-byte JSON and cross-language JCS lanes.
2. Run physical hostile archives, parsers, media, SSRF, secrets, and model/tool-channel tests.
3. Complete provider A → B → A transfer with unknowns, contradictions, decision history, aliases, and losses.
4. Implement PAM sidecar/loss fixtures in two independent adapters.

### Phase 4 — Define protection and human assurance

1. Select and review remote/offline package security profiles.
2. Test issuer/recipient/key/status/rotation/recovery/downgrade and archival migration.
3. Test accessible consent, processor changes, proposals, revocation, and deletion language with people.
4. Obtain independent security, privacy, accessibility, and coercion-safety review.

### Phase 5 — Establish neutral governance and expand from evidence

1. Adopt license, patent, contribution, registry, appeals, security, trademark, and conformance-mark policies.
2. Recruit independent implementers and publish interoperability reports.
3. Promote conversation, artifact, credential, authority, delegation, erasure, continuity/HIB, and sync profiles only after their own evidence gates.

## 8.12 Final publication recommendation

Publish OCP 0.4 as an **open consolidated editor's working draft for bounded technical review**, accompanied by its exact source, schemas, fixtures, registries, mapping, issue/decision registers, and evidence-status reports. Do not call it production-ready, secure, legally compliant, independently interoperable, or standards-body adopted.

The current source/reference result—**27 / 27 schemas, 23 / 23 positive fixtures, 45 / 45 negative fixtures, 243 / 243 semantic vectors, 29 / 29 registry/OpenAPI/accounting gates, and 107 / 107 assertion rows**—is credible evidence that the package is internally testable and synchronized. It is deliberately not implementation conformance. The decisive next proof is two independent systems exchanging the core while failing safely under widening, stale-state, hostile-input, wrong-recipient, loss, and no-action tests.

If that work shows the useful OCP vertical can be expressed completely as a PAM profile and established authorization/binding profiles, choosing the profile would be a standards success. If the five uniquely governed workflow records and scoped-acceptance semantics continue to require an OCP sidecar, the project will have demonstrated why a separate OCP core is warranted.
