# OCP v0.9 / v0.2 Reconciliation

> **Historical design record.** This reconciliation compared two pre-0.4 branches. OCP 0.4 now supersedes both as the project-authoritative working draft; “current” below means current at the time of this review.

**Purpose:** Determine whether `OCP-Specification-v0.9-draft.md` should replace, merge with, or become a profile of the current validated `OCP-v0.2-Review-Draft.md`, and give the lead editor a section-by-section disposition for every part of the 0.9 draft.

**Inputs reviewed in full:**

- `OCP-Specification-v0.9-draft.md` (`V09`)
- `deliverables/OCP-v0.2-Review-Draft.md` (`V02`)
- `work/next_release_architecture_review.md` (`AR`)

**Status:** Architecture recommendation only. This note does not modify or supersede either specification.

## 1. Bottom line

`V09` and `V02` are **not two successive versions of one settled wire protocol**. They are two protocol concepts that share a philosophy:

- `V02` is a governed-context presentation and transfer protocol: reviewed context, evidence separation, request, external authorization, non-secret receipt, minimized package, proposal, and immutable review decision.
- `V09` is a continuity-observation and evaluation protocol: threads, snapshots, conditions, aggregate continuity state, admissibility markers, upstream-reference resolution, and Human Interaction Continuity state.

Their wire objects, lifecycles, discovery paths, packages, envelopes, conformance classes, and meanings are materially different. Publishing `V09` as the next OCP version would silently replace the validated `V02` core with a second core, while the number `0.9` would imply maturity that neither independent interoperability nor executable security evidence establishes.

They are nevertheless **composable at the suite level**. The sound composition is:

```text
OCP Core 0.4
  governed context semantics and presentation
  context_space, source_record, context_item,
  client_declaration, context_request, grant_receipt,
  context_package, update_proposal, review_decision
        |
        +-- Continuity Observation Profile 0.1-draft
        |     condition observations, evaluation snapshots,
        |     degradation/restoration history, profile-defined markers
        |
        +-- Human Interaction Boundary Profile 0.1-draft
              explicit pause, checkpoint, pacing, and resume signals only
```

The next project-authoritative document should therefore consolidate `V02` as **Open Continuity Protocol 0.4 — Consolidated Editor’s Working Draft**. It should absorb `V09`'s durable invariants and place its new operational concepts in separately versioned profiles. It should not call the merged result `0.9`, should not retain a second `continuity_package`, and should not introduce thread/snapshot/condition objects into the semantic core without implementation evidence.

## 2. Why they compete if merged naively

### 2.1 They answer different primary questions

`V02` asks:

> Which reviewed context may this recipient receive for this purpose, under which current authorization, with which disclosure, retention, processing, and update limits?

`V09` asks:

> Which declared continuity conditions are observable now, what evidence supports their status, and how has that status degraded or been restored?

Both are useful, but neither question subsumes the other. A condition evaluator cannot replace a context authorization or review workflow. A context package cannot by itself describe live source availability, freshness, or a pause/resume condition.

### 2.2 The object models collide rather than extend

`V02` has nine concrete core records and deliberately keeps artifacts, conversations, erasure, transfer mechanics, security mechanisms, and agent behavior outside the semantic core. `V09` instead centers:

- `ContinuityThread`;
- `ContinuitySnapshot`;
- `ConditionObservation`;
- `UpstreamReference`;
- `AuthorityBinding`;
- `HICState`;
- `ContinuityEvent`; and
- a different `ContinuityPackage` manifest.

These are not additive fields on the `V02` records. They create parallel meanings for scope, history, source, authorization, package, event, and current state. The package-name collision alone is release-blocking: a `V02 context_package` is a minimized, audience-bound context presentation under one active receipt; a `V09 continuity package` is a thread/snapshot/event handoff archive.

### 2.3 The safety posture is stronger in `V02`

`V09` states the crucial invariant “visibility is never authorization,” but `V02` operationalizes it more completely through:

- a non-secret `grant_receipt` that is explicitly not a credential;
- an operation-time authorization intersection;
- `external_action_authority: "none"` in every core package;
- strict request/receipt/package containment;
- an authenticated client instance and current declaration;
- baseline delegation exactly `none`;
- package-local and audience-pairwise identifier rewriting;
- import quarantine and a prohibited `mapped -> accepted` transition;
- explicit unavailability of unimplemented remote/offline security claims; and
- proposal plus immutable decision before accepted-state change.

`V09` has the right principles, but its examples and interfaces do not yet enforce equivalent boundaries.

### 2.4 The version histories cannot both be authoritative

`V09` is dated 11 August 2026 and labels itself `0.9-draft`; `V02` is dated 12 August 2026 and is the implementation-facing, companion-validated baseline. Version numbers cannot be used to override source authority. A later wire number without a migration, schema suite, executable fixtures, or editorial decision is not a successor release.

The source history should record `V09` as an architectural proposal that contributed a Continuity Observation Profile and HIC design input, not as an already published protocol version.

## 3. Concepts from v0.9 worth retaining

The following concepts are materially valuable. “Retain” does not mean copy the current wire shape unchanged.

| `V09` concept | Disposition | Destination in the next suite | Required reconciliation |
|---|---|---|---|
| Observation before interpretation | **Accepted** | Core invariant | Express as evidence/origin before provider interpretation and review; keep acceptance as an independent dimension. |
| Visibility is never authorization | **Accepted** | Core immutable invariant | Use `V02`'s stronger package/action boundary and operation-time authorization rules. |
| `source_authority` distinct from `runtime_source` | **Modified** | Core provenance vocabulary plus profile capture metadata | Preserve origin/source authority, capture/adapter runtime, evaluator, and recipient as separate roles. Do not imply that a source reference proves authority. |
| Observe-only behavior | **Accepted** | Core invariant; profile interface rule | Define as “no external-domain action authority or operation.” OCP still creates its own records, receipts, snapshots, and audit events. |
| Bounded subject, purpose, scope, and time | **Accepted** | Core | Reuse `context_space`, request, receipt, and package dimensions rather than create a parallel thread boundary. |
| Append-only degradation/restoration history | **Modified** | Continuity Observation Profile | Use immutable observations/evaluations linked to the affected OCP record or source; never rewrite prior accepted records. |
| Condition status: `satisfied`, `unsatisfied`, `indeterminate`, `not_applicable` | **Modified** | Continuity Observation Profile | Keep only as evaluation results under an exact named profile. `indeterminate` must never become satisfied. Do not make these universal truth states. |
| Exact policy/evaluation profile version | **Accepted** | Continuity Observation Profile and conformance | Pin schema, registry, evaluator version, inputs, clock, and resolver results. |
| Deterministic evaluation for fixed inputs | **Accepted** | Continuity Observation Profile | Require executable fixtures and prohibit an LLM from deciding core containment or condition truth without a profile-defined method. |
| Freshness separated from validity | **Accepted** | Core time semantics plus observation profile | Preserve `observed_at`, `acquired_at`, evaluation time, age, limit, clock source, and uncertainty distinctly. |
| Explicit source availability and dependency | **Accepted with terminology change** | `source_record` and Artifact/Lineage Profile | Use `reference_only`, `derivative_only`, `managed_copy`, and `synchronized_copy` rather than an unqualified `preserved` claim. |
| Upstream lineage and typed reference roles | **Modified** | Core provenance and Artifact/Lineage Profile | Reuse source records and profile links. Do not introduce a second universal `UpstreamReference` record unless prototypes require one. |
| Restoration does not erase degradation | **Accepted** | Continuity Observation Profile | A restoration links the earlier degradation, new basis, evaluation time, and resulting state. |
| Conflicts remain visible | **Accepted** | Core accepted-context semantics and observation profile | Preserve contradictory evidence/items and evaluation uncertainty; no last-write-wins or confidence overwrite. |
| Unknown optional extensions survive; unknown critical extensions fail closed | **Accepted** | Core | Preserve/loss-report unknown non-critical JSON and quarantine it from rendering or model use. |
| Fork/merge history | **Deferred** | Live Sync / Multi-writer Profile | Current optimistic concurrency remains core. Fork/merge semantics need prototypes, profile-specific conflict rules, and tests. |
| RFC 9457 errors | **Accepted** | HTTP Binding | Use the existing `V02` problem-details model and error registry. |
| CloudEvents-compatible reference-first events | **Modified** | Event Binding | Keep events free of content, tokens, and authority; resource state remains authoritative. |
| Resolver isolation and SSRF resistance | **Accepted** | Import/Reference Retrieval Profile | Require scheme/host controls, redirect/DNS rechecks, no ambient credentials, quantitative bounds, and an `indeterminate` result. |
| Human-declared pause and resume | **Modified** | Human Interaction Boundary Profile | Retain explicit control/declaration, checkpoint, expiry, inspect/correct/delete, and fresh revalidation on resume. |
| No covert biometric or behavioral inference | **Accepted** | HIC/Human Interaction Boundary Profile invariant | Prohibit facial, voice-stress, keystroke, covert sentiment, demographic-proxy, and silence-based sensitive inference. |
| Human pacing is local and reversible | **Accepted** | HIC/Human Interaction Boundary Profile | Default local, short-lived, purpose-bound, no training reuse, no cross-purpose disclosure. |
| “No hidden blocking” accountability | **Modified** | Core external-action boundary and audit | OCP emits data only. A host that blocks or acts must record its separate policy decision and authority basis. |
| Context/evidence/archive permission separation | **Accepted** | Core | `V02` already implements the stronger views model. |
| Interaction events do not automatically become preferences | **Accepted** | Source/adapter rules | Require explicit observation → interpretation → proposal → review transitions. |
| Erasure receipt is not proof of erasure | **Accepted** | Erasure Status Profile | Keep `V02`'s more exact status and evidence vocabulary. |
| Composition with OAuth, MCP, A2A, PROV, C2PA, VC, CloudEvents, OpenTelemetry, PAM, and DPV | **Accepted with pinning** | Bindings/mappings | Each mapping must name an exact source version, boundary, cardinality, loss behavior, and negative fixtures. |
| Condition/evaluation telemetry without raw content | **Accepted** | Event/Telemetry Binding | Use low-cardinality aliases; never emit stable person IDs, free-text HIC signals, evidence, prompts, or artifacts by default. |

## 4. Unsafe, ambiguous, or underspecified areas in v0.9

### 4.1 Version and authority

- `0.9` signals near-candidate maturity despite no demonstrated independent interoperability, complete schema catalog, executed fixture suite, registered cryptographic profile, or independent review.
- `opencontinuity.org` is called canonical without the release manifest, durable namespace governance, or source hierarchy needed to make that claim operational.
- No migration maps `V02` records, states, package semantics, errors, profiles, or identifiers into `V09`.
- “Complete enough for prototype implementations” is not backed by an executable companion comparable to the current `V02` pack.

### 4.2 Competing packages and envelopes

- `continuity_package` conflicts semantically with `context_package`. One carries thread/snapshot/event history; the other is a minimized recipient presentation under a receipt.
- The universal common envelope requires subject, source, runtime source, and `authority_effect` concepts that do not fit discovery documents, RFC 9457 problems, or CloudEvents. `V02` correctly uses envelope families.
- `object_type` replaces the validated `type` plus exact `schema_uri` pattern without a migration or registry artifact.
- The Appendix A schema is explicitly an excerpt, permits broad `additionalProperties`, omits many cross-object conditions, and cannot substantiate the normative examples.

### 4.3 Authorization and credential confusion

- `visibility grant` duplicates `V02`'s request/receipt/external authorization division but is not modeled with comparable containment and lifecycle precision.
- `AuthorityBinding` exposes issuer, subject, resource, authorization reference, reported state, audience, and freshness in a portable object. Without strict minimization and binding rules it can become a correlation surface or be mistaken for a credential/status proof.
- The runtime endpoints require generic visibility authorization but do not define the exact operation-time intersection across client instance, receipt, purpose, audience, views, time, retention, use, delegation, offline use, and local policy.
- The evaluation request uses a DPoP authorization example, but DPoP sender-constrains an OAuth access token; it does not authenticate a continuity package or protect recipient plaintext.

**Recommendation:** do not adopt `VisibilityGrant` or `AuthorityBinding` as new core records. Use `V02`'s `context_request`, external authorization, `grant_receipt`, status lookup, and exact binding profiles. A continuity observation may reference a receipt/status evaluation result without containing credentials or reusable authorization material.

### 4.4 “Admissibility” can be read as permission

`V09` repeatedly disclaims authority, but the term `admissible` is naturally interpreted as “allowed to proceed,” especially in legal, financial, health, safety, and autonomous-agent systems. Its four states and policy thresholds are not mechanically defined across domains.

**Recommendation:** reject `admissibility` as a core OCP object/state. If an experiment needs it, use a profile-specific `continuity_evaluation_result` with a named policy, exact decisive conditions, `external_action_authority: "none"`, and a prohibition on direct external-action gating. The host owns and audits any separate decision.

### 4.5 Aggregate continuity state is too universal

`intact`, `strained`, `degraded`, `broken`, and `indeterminate` are intuitive but risk becoming universal scores over a person, agent, case, or organization. The transition rules depend on undefined concepts such as “foundational binding,” profile thresholds, criticality, and reconstruction. Two implementations can validly produce different aggregates from the same observations.

**Recommendation:** retain individual condition observations first. Defer the common aggregate registry until at least two independent evaluators demonstrate deterministic agreement. Any earlier aggregate belongs to a named domain profile and must state that it is scoped, time-bound, non-authoritative, and not a person score.

### 4.6 HIC reifies sensitive human state

The best part of HIC is explicit pause/checkpoint/resume portability. Its riskier vocabulary—`fear_of_error`, `overload`, `hesitation`, `uncertainty`, “steady,” and “reduced pace”—can be interpreted as psychological state even when the draft says otherwise.

Specific problems include:

- a deterministic signal the user has enabled can still turn behavior into a sensitive inference;
- raw free-text signals can expose highly sensitive content;
- placing HIC in a general snapshot makes cross-runtime propagation easy;
- `suggested_markers` such as `preserve_checkpoint` can become an instruction surface;
- disclosure, retention, expiration, training, correction, coercion, accessibility, and recipient assurance need a complete profile and fixtures; and
- an authorized application may over-rely on the HIC state despite `authority_effect: none`.

**Recommendation:** place HIC outside core in a **Human Interaction Boundary Profile**. The initial profile should support only explicit user controls/declarations for `pause`, `checkpoint`, `slower_pacing`, `clarification_requested`, and `resume`, with exact expiry and disclosure rules. Defer portable `fear_of_error`, `overload`, `hesitation`, and inferred uncertainty semantics pending human-factors, accessibility, privacy, coercion-safety, and misuse review.

### 4.7 Identifier privacy is stated but not implemented

`V09` recommends pairwise or scope-local subject identifiers, but the common examples repeatedly carry the same subject and thread identifiers through records and packages. It does not define store, export, package, and audience identifier domains or a rewrite completeness check.

**Recommendation:** keep `V02`'s stronger rule: store-internal IDs stay private; runtime packages use audience-pairwise and package-local aliases; every matching reference is rewritten; the map stays provider-side; user-directed transfer uses separately authorized continuity IDs and reports mapping/loss.

### 4.8 Cryptographic claims are not executable

- The abstract calls the account “tamper-evident,” while example signatures are `null` and no signed representation, trust model, recipient encryption format, key discovery/status, algorithms, or vectors are registered.
- Federated deployments are described as exchanging signed packages without a profile.
- TLS and at-rest encryption guidance do not protect a durable archive or bind a package to a client instance.
- A digest proves byte equality, not issuer authenticity.

**Recommendation:** preserve `V02`'s honest unavailability boundary. Remote Security, offline protection, and protected transfer remain unclaimable until registered signature/encryption profiles and positive/negative vectors exist.

### 4.9 Continuity conditions lack a safe registration contract

The condition registry mixes technical facts (`source.resolvable`), authorization-status observations (`authority.binding_current`), semantic judgments (`scope.consistent`), preservation claims (`artifact.independent`), human interaction (`human.pacing_supported`), and governance qualities (`conflict.visible`). Their evaluation methods and proof thresholds are not defined.

**Recommendation:** a condition registration must specify identifier, version, subject/resource scope, inputs, evaluator method, result rules, freshness, resolver policy, privacy category, false-positive/negative risks, decisive effect, restoration semantics, tests, and prohibited interpretations. Core should not ship a universal condition registry before those contracts exist.

### 4.10 Examples and schemas do not form a validated set

- Several examples use mnemonic values with a `urn:uuid:` prefix, such as `urn:uuid:pause-1`, `urn:uuid:review-1`, and `urn:uuid:ocp-snapshot-1`; these are not valid UUID URNs.
- Some examples are fragments rather than schema-valid top-level records.
- HIC resumed events use a different envelope from the CloudEvents model.
- The Appendix A schema is not a complete schema set and uses permissive `additionalProperties` in security-relevant places.
- There is no machine-readable assertion registry, expected-negative metadata, semantic comparator, or validation report.

**Recommendation:** treat every `V09` example as an informative design sketch. Rebuild any adopted profile objects in the next companion pack and validate them with positive, negative, hostile, transition, downgrade, alias, authorization, and round-trip fixtures.

### 4.11 Third-party and organizational authority are too broad

`V09` includes organizational handoff, human approval sequences, agents, and a portable human runtime, but does not carry `V02`'s conservative authority boundary for self, household, guardian, coercion-sensitive, minor, and organization-managed data.

**Recommendation:** the continuity profiles inherit all Core Personal exclusions. Any evaluation over multi-party or organizational records requires the matching authority profile; an observation of an authority record is never proof that the exporter or recipient may disclose or act.

### 4.12 Canonical context regresses terminology and governance

`V09` defines canonical context and an undefined “authorized canonicalization process.” `V02` deliberately deprecates that term, represents accepted context as scoped governance state, and requires proposal/decision evidence.

**Recommendation:** use `accepted context` only. “Canonical” remains limited to deterministic bytes. A provider interpretation becomes accepted only through a proposal/review decision or an explicitly registered review policy; its epistemic origin does not change.

## 5. Recommended next authoritative architecture

### 5.1 Version and title

Recommended identity:

- **Document title:** `Open Continuity Protocol 0.4 — Consolidated Editor’s Working Draft`
- **Project status:** `Current project-authoritative draft until superseded`
- **Standards status:** `Not an adopted standard, security certification, production recommendation, or independent-interoperability claim`
- **Wire version:** `0.4` only because the reconciliation is expected to change classification, identifier domains, normative-source structure, and possibly core `context_item.kind` semantics
- **Profile versions:** independent `0.1-draft` identifiers

If the editor makes no representation or semantic change and only archives `V09` as design input, the honest version would be a document-only `0.2.1-editor-draft` with wire `0.2`. The project should not increment wire version solely to communicate editorial activity.

### 5.2 Core record set

Retain the nine `V02` concrete core records:

1. `context_space`
2. `source_record`
3. `context_item`
4. `client_declaration`
5. `context_request`
6. `grant_receipt`
7. `context_package`
8. `update_proposal`
9. `review_decision`

The common definitions schema remains a schema family rather than a tenth record. Transfer manifests, offline manifests, adapter fixtures, discovery documents, problem details, events, and observation snapshots should be classified by binding/profile/conformance purpose, not smuggled into the semantic core by directory placement.

### 5.3 Binding, profile, mapping, and conformance split

**Bindings**

- Remote HTTP
- OAuth/RAR authorization
- Local broker
- Offline archive
- Transfer
- Events/telemetry

**Domain profiles**

- Conversation/Message
- Artifact/Lineage
- Work Context if `goal`, `decision`, and `instruction` need portable semantics
- Credential Evidence
- Erasure Status
- Organization Authority/Custody
- Household/Joint Context
- Delegation/Agent Chain (experimental)
- Live Sync/Multi-writer (experimental)
- Continuity Observation
- Human Interaction Boundary

**Security profiles**

- Remote package authenticity/confidentiality
- Offline archive protection

**Mappings**

- PAM first, then PROV, MCP, A2A, C2PA, VC/SD-JWT, Solid, DPV, CloudEvents/OpenTelemetry

**Conformance**

- Actor-specific classes and evidence; profiles are not marketing tiers and green fixtures are not release, deployment, security, or live-user evidence.

## 6. Placement decision for v0.9 objects

| `V09` object/concept | Core | Profile/binding | Deferred/rejected | Decision |
|---|---:|---:|---:|---|
| `ContinuityThread` | No | Continuity Observation Profile only if needed | Current standalone object deferred | Prefer `context_space` plus profile linkage; do not create a second scope root until prototypes prove it necessary. |
| `ContinuitySnapshot` | No | Continuity Observation Profile | — | Immutable evaluation result linked to exact OCP revisions, sources, profile, time, and evaluator. |
| `ConditionObservation` | No | Continuity Observation Profile | Universal condition registry deferred | Retain four-valued status and basis/freshness, with registration contract and fixtures. |
| Aggregate state | No | Domain-specific observation profile, experimental | Universal `intact/strained/degraded/broken` registry deferred | Require independent deterministic evaluation evidence before generalization. |
| Admissibility | No | At most an experimental named policy result | Core term/state rejected | Too easily confused with authorization or permission. |
| `UpstreamReference` | No new record | Core provenance plus Artifact/Lineage/Reference Retrieval profiles | Standalone universal record deferred | Reuse `source_record`, content references, provenance, custody, and availability. |
| `AuthorityBinding` | No | Authorization Binding status evidence only | Portable authority object rejected | Use external authorization and non-secret receipt; never package credentials/status as authority. |
| `HICState` | No | Human Interaction Boundary Profile | Sensitive inferred classes deferred | Explicit declarations/controls only in the initial profile. |
| `ContinuityEvent` | No | Event Binding | — | CloudEvents-compatible, reference-first, content-minimized, never state/authority of record. |
| `ContinuityPackage` | No | None under this name | Rejected due collision | Use `context_package` for runtime presentation and offline/transfer manifests for durable movement. |
| Policy profile | No concrete core object yet | Evaluation/profile catalog | Declarative universal policy language deferred | Pin exact profile/schema/digest and executable evaluator behavior. |
| HIC Runtime | No | Rename as Human Interaction Boundary Profile | Runtime/execution framing rejected | “Runtime” can imply control; the profile carries explicit boundary signals as data. |

## 7. Specific decision: HIC and continuity conditions

### 7.1 HIC

**Disposition: Modified; profile, not core.**

The initial Human Interaction Boundary Profile should contain only:

- explicit user-declared or user-control signals;
- `pause_requested`, `checkpoint_requested`, `slower_pacing_requested`, `clarification_requested`, and `resume_requested`;
- a profile-local opaque subject alias;
- exact purpose, audience, scope, created/observed/expiry times;
- signal origin and interface method;
- checkpoint reference without raw context;
- inspection, correction, dismissal, deletion, and non-disclosure rules;
- `external_action_authority: "none"`;
- a prohibition on training, advertising, cross-purpose scoring, hidden urgency, diagnosis, capacity claims, and action authorization; and
- revalidation of time-sensitive OCP and external authorization state on resume.

It should not initially standardize `fear_of_error`, `overload`, `hesitation`, inferred uncertainty, severity, competence, capacity, or emotion. Those concepts are **Deferred** until reviewed by human-factors, privacy, accessibility, coercion-safety, clinical-boundary, and affected-user experts and supported by real UI tests.

### 7.2 Continuity-condition objects

**Disposition: Modified; profile, not core.**

A minimum Condition Observation object may include:

- condition definition URI and version;
- target OCP record/revision or external source reference;
- result: satisfied, unsatisfied, indeterminate, or not applicable;
- basis references;
- observation and evaluation times;
- freshness limit/state and clock source/uncertainty;
- evaluator and method/profile version;
- reason codes;
- prior observation reference when recording change;
- privacy/sensitivity classification;
- `external_action_authority: "none"`; and
- immutable extensions.

It must not contain action instructions, credentials, hidden model reasoning, or a general person score. An observation never mutates accepted context; it may become evidence for a separately authorized proposal or host-policy decision.

### 7.3 Aggregate, restoration, and thread objects

- **Restoration/degradation events:** include in the Continuity Observation Profile after the individual condition object exists.
- **Aggregate state:** defer a universal registry; allow only named profile algorithms with fixtures.
- **Thread object:** defer. First attempt to use `context_space`, correlation IDs, revisions, and profile-local evaluation sequences.
- **Snapshot object:** profile object, not core. It is an immutable evaluation over exact inputs, not the authoritative accepted-context store.

## 8. Section-by-section disposition map for v0.9

Disposition terms follow the governing review vocabulary: **Accepted**, **Modified**, **Partial**, **Rejected**, **Deferred**, and **Superseded**.

| `V09` section | Disposition | Destination / reason |
|---|---|---|
| Title, metadata, and status | **Superseded** | Do not publish `0.9-draft` or “Public Review Draft” as the successor. Record it as design input; use the 0.4 editor’s working-draft identity and evidence-bounded status. |
| Status-of-document BCP 14 rule | **Accepted** | Retain BCP 14 treatment, actor clarity, and examples-informative rule. Replace the vague prose/schema precedence with scoped normative authority and a release manifest. |
| Status invariant “visibility is never authorization” | **Accepted** | Promote as immutable core invariant; implement through `V02` request/receipt/package/action separation. |
| Abstract | **Partial** | Retain observation/preservation thesis and source/runtime distinction as profile rationale. Reject the implication that thread/snapshot/HIC are the OCP core and the unsupported “tamper-evident” claim. |
| 1. Motivation and goals | **Partial** | Retain continuity failures, referent loss, authority freshness, lineage, and pause-boundary examples. The four continuity questions become Continuity Observation Profile scope; the primary OCP mission remains governed-context presentation/transfer. |
| 1.2 Primary goals | **Modified** | Observation, history, non-inheritance, lineage, portability, inspectability, and composition remain. HIC is a separate profile; transport neutrality is achieved by bindings rather than a universal runtime API. |
| 1.3 Non-goals | **Accepted with additions** | Strongly compatible with `V02`. Add no silent accepted writes, no recipient-behavior proof, no universal aggregate person score, and no implemented-crypto claim without profiles/vectors. |
| 2. Design horizon 2026–2031 | **Partial** | Keep informative and explicitly non-predictive. Reverify every time-sensitive standards claim at release. Move product-specific dated references out of normative reasoning. |
| 2.1–2.4 agent, observability, authorization, provenance horizon | **Modified** | Use as mapping priorities, not proof that OCP needs a second core. External identity/auth remain mandatory; DPoP does not secure packages; provenance does not prove truth/rights/acceptance. |
| 2.5–2.7 portability, multimodal, human pacing horizon | **Accepted with profile placement** | Strengthen PAM field/lifecycle mapping; keep artifacts and human boundaries in profiles with explicit privacy and authority rules. |
| 2.8 stable design bet | **Modified** | Keep scoped, non-authoritative visibility, but pair it with `V02`'s reviewed-context and no-action invariants. |
| 3. Terminology | **Partial** | Reconcile every term with the 0.4 glossary. Avoid duplicate meanings for package, snapshot, source, scope, profile, grant, and state. |
| 3.1 `Canonical context` | **Superseded** | Use `accepted context`; “canonical” only for deterministic representation. |
| 3.1 `Visibility grant` | **Rejected as new OCP record** | Use external authorization plus `grant_receipt`; possession of the receipt never grants access. |
| 3.1 `Admissibility` | **Rejected as core term** | At most a profile-specific non-authoritative evaluation result. |
| 3.1 continuity-condition/snapshot/thread terms | **Modified** | Define in the Continuity Observation Profile, not core. |
| 3.2 HIC terms | **Partial / Deferred** | Explicit pause/pacing/clarification/resume terms proceed to profile. Fear, overload, hesitation, and inferred uncertainty semantics are deferred. |
| 4. Design principles | **Accepted with reconciliation** | Most principles are durable. They become core architecture decisions or profile constraints rather than evidence for `V09`'s object model. |
| 4.1–4.10 observation, authority, scope, history, lineage, minimization, independence | **Accepted / Modified** | Merge with `V02` evidence/interpretation/acceptance, no-action, pairwise identifier, artifact custody, and honest assurance rules. |
| 4.11 human boundaries | **Modified** | Profile-only, local and short-lived by default, with explicit disclosure/expiry/correction/deletion controls. |
| 4.12 fail visible | **Accepted** | Unknown/stale/conflicting/unavailable inputs fail closed or become indeterminate; never silently intact/accepted. |
| 4.13 no hidden blocking | **Modified** | OCP does not authorize or execute the block. Hosts may make external decisions and must attribute them to their own policy/authority. |
| 4.14 compose, do not compete | **Accepted** | Preserve as an editorial test for every profile and mapping. |
| 5. Architecture | **Modified** | Treat observer/evaluator functions as an optional profile implementation, not the semantic core architecture. Keep evidence/authority/continuity/execution separation as an explanatory view. |
| 5.1 governance-chain diagram | **Accepted with wording changes** | Dependency never means authority inheritance. Replace “readiness/admissibility” with a neutral evaluation result to reduce permission confusion. |
| 5.2 logical components | **Partial** | Observer/evaluator may implement a profile; store/packager/gateway map to existing provider/bindings. Do not create mandatory deployment components. |
| 5.3–5.4 layer boundaries and deployments | **Modified** | Reuse `V02` role and deployment distinctions; add the optional observation layer without weakening current authorization and privacy constraints. |
| 5.5 object relationships | **Rejected as core / Deferred as profile sketch** | Do not replace the nine-record core. Prototype a profile graph that references `context_space`, source records, accepted revisions, receipts, and packages. |
| 6. Core concepts | **Modified / Profile** | Non-inheritance and source/runtime separation are core invariants. Conditions, threads, snapshots, and restoration records are profile semantics. |
| 6.1 continuity conditions | **Modified / Profile** | Retain four-valued status and basis/freshness; require a registration contract, privacy classification, and fixtures. |
| 6.2 admissibility | **Rejected as core** | Rename to profile-specific evaluation result if retained. Never use it as direct action authorization. |
| 6.3 continuity threads | **Deferred** | First use `context_space` plus profile-local evaluation sequence. A new root record requires implementation evidence. |
| 6.4 snapshots | **Modified / Profile** | Immutable profile result linked to exact inputs; not the accepted-context current-state row. |
| 6.5 authority hierarchy | **Accepted with mapping** | Preserve originator, source authority, capture runtime, evaluator, and consumer roles; represent actual review/authorization with `V02` records and external systems. |
| 6.6 non-inheritance | **Accepted** | Promote to immutable invariant and executable negative tests. |
| 6.7 observe-only boundary | **Accepted with clarification** | No external domain execution or authority. OCP may create its own immutable protocol records under authorization. |
| 6.8 upstream preservation | **Modified** | Fold into source/artifact custody and reference-retrieval profiles; replace “canonical copy” with evidence-bounded managed-copy claims. |
| 6.9 restoration/degradation | **Modified / Profile** | Preserve append-only history linked to exact condition observations and basis. |
| 6.10 provider interpretation/canonical context | **Superseded** | `V02`'s evidence → provider interpretation → proposal/review → accepted context model controls. |
| 7. Core data model | **Rejected as a competing core** | Do not adopt its envelope or object family as OCP 0.4 core. Rebuild selected condition/HIC objects under separate profile URIs and schemas. |
| 7.1 serialization/media types | **Partial** | JSON Schema 2020-12 remains. Provisional media types stay provisional and belong to bindings/registration work. |
| 7.2 common envelope | **Rejected / Superseded** | Use envelope families and exact `schema_uri`; do not force CloudEvents, discovery, problems, or all records into one shape. |
| 7.3 `ContinuityThread` | **Deferred** | Profile experiment only; avoid duplicating `context_space`. |
| 7.4 `ContinuitySnapshot` | **Modified / Profile** | Rebuild as a strict profile schema after condition registration. |
| 7.5 `ConditionObservation` | **Modified / Profile** | Retain a strict minimal form; add privacy, exact definition URI, target revision, and non-action field. |
| 7.6 `UpstreamReference` | **Modified / Folded** | Map fields into `source_record`, provenance, content references, and Artifact/Lineage profile. |
| 7.7 `AuthorityBinding` | **Rejected as portable authority object** | Reference a `grant_receipt` or external status evidence; operation-time authorization stays outside. |
| 7.8 `HICState` | **Modified / Profile** | Narrow to explicit boundary signals; package-local alias; no raw free text by default; no inferred sensitive state. |
| 7.9 `ContinuityEvent` | **Modified / Binding** | Use a single CloudEvents-compatible envelope with reference-first minimized data. |
| 7.10 continuity-package manifest | **Rejected due name/semantic collision** | Use `context_package` and the separate offline/transfer bindings. |
| 8. State and evaluation | **Deferred / Profile** | Useful experimental design, not stable core. Individual condition results precede any universal aggregate. |
| 8.1 core condition registry | **Rejected as current core registry** | Split technical/source, authorization-status, artifact, human, and governance conditions into versioned profiles with exact methods and fixtures. |
| 8.2 aggregate states | **Deferred** | No universal `intact/strained/degraded/broken` claim until independent evaluators agree. |
| 8.3 transitions | **Partial** | Append-only change/restoration is sound; exact transitions belong to each evaluation profile. |
| 8.4 evaluation algorithm | **Modified / Profile** | Retain deterministic-input requirement; specify resolver results, clock, external observations, and no LLM-based core containment. |
| 8.5 freshness | **Accepted** | Integrate with core time glossary and profile observations. |
| 8.6 conflict handling | **Accepted** | Preserve conflicts and require explicit review/resolution; example fragments must be rebuilt as valid fixtures. |
| 9. Runtime interfaces | **Rejected from core / Deferred as binding** | Do not add a second discovery path or endpoint family. Define any observe/evaluate operations as an optional binding over 0.4 resources. |
| 9.1 discovery | **Modified** | Extend the 0.4 discovery document with supported observation/HIC profile versions; exact issuer/resource comparison and capability spoofing tests required. |
| 9.2 endpoints | **Deferred** | Profile binding only; no generic `/evaluate` claim until authorization, data model, idempotency, errors, and limits are executable. |
| 9.3 idempotency/concurrency | **Accepted** | Reuse `V02`'s stronger principal/endpoint/version/canonical-digest binding and ETag rules. |
| 9.4–9.5 evaluation request/response | **Rejected as normative examples** | DPoP does not solve package security; schemas, auth containment, and profile semantics are incomplete. Rebuild as fixtures if the profile proceeds. |
| 9.6 minimal integration flow | **Modified** | Preserve external host-policy/action step, but insert current request/receipt authorization and untrusted-data handling. |
| 9.7 observability markers | **Partial** | Useful low-cardinality attributes; remove raw HIC/free text and stable person/thread identifiers. |
| 9.8 errors | **Superseded / Folded** | Use the existing RFC 9457 error model and governed registry; add profile-specific codes through namespaced registration. |
| 10. Human Interaction Continuity Runtime | **Modified / Profile** | Rename/reframe as Human Interaction Boundary Profile. It observes explicit boundaries; it is not a runtime or decision engine. |
| 10.1–10.2 purpose/activation | **Partial** | Explicit controls/declarations accepted. Enabled deterministic behavioral inference and accessibility-profile disclosure need strict profile review. |
| 10.4–10.4 signals/states | **Partial / Deferred** | Pause/checkpoint/clarification/slower pace/resume retained. Fear, overload, hesitation, inferred uncertainty, and broad state labels deferred. |
| 10.5 behavioral rules | **Accepted with strengthening** | Add package-local IDs, no free text by default, no cross-purpose scoring, no training, strict retention/expiry, trusted UI, and profile fixtures. |
| 10.6 consequential actions | **Accepted** | HIC never decides capacity, consent, legality, safety, or action permission. |
| 10.7 resume semantics | **Modified / Profile** | Retain checkpoint and fresh revalidation; remove invalid example IDs and use one event/binding family. |
| 11. Portable context and artifact continuity | **Mostly Superseded by `V02`** | `V02` already gives a more precise context/evidence/artifact view model, import quarantine, package authorization, custody, transfer, and erasure semantics. |
| 11.1 context is not a dossier | **Accepted** | Core minimization invariant. |
| 11.2–11.3 three layers and permissions | **Accepted with terminology update** | Evidence → provider interpretation → accepted context; archive/artifact content remains separate permission. |
| 11.4 artifacts first-class | **Modified** | Artifacts are first-class profile objects, not core objects. Use custody and evidence requirements from `V02`. |
| 11.5 referential continuity | **Accepted** | Retain versioned artifact/entity relationships and loss reporting in profiles. |
| 11.6 conversation graphs | **Accepted / Profile** | Conversation/Message Profile preserves branches and untrusted source roles. |
| 11.7 interaction signals | **Accepted with containment** | Keep as source observations; never auto-promote to preference or accepted context. |
| 11.8 transfer/erasure | **Superseded / Folded** | Use `V02` transfer lifecycle and Erasure Status Profile. |
| 12. Interoperability profiles | **Modified** | Retain as mapping inventory, but split binding, domain profile, security profile, mapping, and conformance taxonomies. |
| 12.1 division of responsibility | **Accepted with exact mappings** | Add lifecycle/cardinality/loss/proof boundaries and pin exact source versions. |
| 12.2 OAuth visibility profile | **Superseded / Folded** | Use the 0.4 OAuth/RAR Authorization Binding. No domain actions in authorization details. |
| 12.3 MCP profile | **Modified** | Optional carriage/binding; metadata hints are not security enforcement or action authority. |
| 12.4 A2A profile | **Modified** | Optional carriage; recipient revalidates integrity, audience, freshness, and independent authorization. |
| 12.5 provenance mapping | **Accepted with limits** | PROV/C2PA do not supply acceptance, truth, rights, or preservation. |
| 12.6 credential profile | **Accepted / Profile** | Keep proof validity, issuer trust, status, acceptance, and action authorization as separate decisions. |
| 12.7 DPV profile | **Accepted as optional mapping** | Pin version and human-readable semantics; no legal conclusion. |
| 13. Behavioral rules and constraints | **Partial / Folded** | Most negative invariants belong in 0.4 core/security/conformance; continuity-specific activation and markers belong to profiles. |
| 13.1 mandatory rules | **Accepted with terminology changes** | Replace canonical-context and universal snapshot rules; keep no authority inheritance, provenance, visible failure, and evidence separation. |
| 13.2 activation | **Modified** | Authorization and necessity required; profile must define quantitative limits and privacy rules. |
| 13.3 non-blocking | **Modified** | Host owns any decision; require separate policy/action audit as `V02` describes. |
| 13.4 no silent mutation | **Accepted** | Reuse immutable proposal/review/revision model. |
| 13.5 business-logic boundary | **Accepted** | External effects remain out of OCP. |
| 13.6 imported instruction isolation | **Accepted** | Merge with stronger `V02` quarantine/parser/action-channel rules and hostile fixtures. |
| 13.7 restoration recommendations | **Modified** | Non-executable profile reason/hint codes only; no privileged instruction surface. |
| 14. Security, privacy, and governance | **Partial / Superseded by stronger `V02` treatment** | Retain threats and core invariants; use `V02` authorization, alias, import, third-party, key, assurance, and governance controls. |
| 14.1 objectives | **Modified** | Remove unimplemented integrity/authenticity guarantees; state intended objectives and unavailable claims. |
| 14.2 threat model | **Accepted with additions** | Retain authority smuggling, continuity laundering, poisoning, lineage, replay, scope, correlation, HIC, dependency, and erasure threats; add BOLA, client substitution, declaration fraud, parser resource attack, organization/coercion, and key recovery. |
| 14.3 authorization | **Superseded / Folded** | Use exact 0.4 remote/local binding rules and operation-time containment. |
| 14.4 integrity | **Deferred to security profiles** | JCS/digests are useful; signatures require a concrete covered view, trust, status, algorithms, and vectors. |
| 14.5 encryption | **Deferred to security profiles** | TLS and generic at-rest advice are insufficient for a protected portable package. |
| 14.6 privacy | **Partial** | Pairwise IDs, minimization, layered views, retention, no-training default retained; add trusted review UI and assurance relationships. |
| 14.7 third-party data | **Superseded / Strengthened** | Apply `V02`'s conservative personal-core exclusions and profile requirements. |
| 14.8 governance | **Accepted as target** | It is a roadmap requirement, not present operational evidence. |
| 14.9 audit | **Modified** | Minimize identifiers; never log free-text purpose/HIC/context; state authorization and access for audit reads. |
| 15. Errors, edge cases, and degradation | **Partial / Profile and fixture input** | Useful cases should become governed error codes and positive/negative semantic fixtures. |
| 15.1 errors | **Modified** | Map to the 0.4 error registry; define retryability and non-disclosure. |
| 15.2–15.4 missing/stale/clock | **Accepted / Profile** | Required inputs fail visibly; clock uncertainty produces indeterminate for time-sensitive evaluation. |
| 15.5 partial packages | **Accepted / Binding** | Manifest must distinguish omission, unavailable, redacted, unauthorized, corrupted, unsupported. |
| 15.6–15.7 forks/merges | **Deferred** | Live Sync / Multi-writer Profile after experiments. |
| 15.8 unknown extensions | **Accepted** | Core invariant and round-trip test. |
| 15.9 HIC ambiguity | **Modified / Profile** | Neutral clarification is acceptable; no person label. Inferred classes remain deferred. |
| 15.10 source deletion | **Accepted** | Preserve origin, change availability, retain managed copy only with evidence, re-evaluate dependents. |
| 16. Versioning, extensibility, compatibility | **Partial / Superseded** | Retain immutable invariants, critical-extension behavior, registries, and deprecation principles; replace `0.9` compatibility assumptions with 0.4 suite versioning and migration notes. |
| 16.1–16.2 version/compatibility | **Modified** | Separate wire, schema, profile, registry, event, and record revision. Never assume later `0.x` semantics are safe merely because fields are optional. |
| 16.3 immutable invariants | **Accepted** | Add accepted-state review, package/action separation, pairwise identifier domains, and no security/erasure overclaim. |
| 16.4 extensions | **Accepted with `V02` behavior** | Unknown non-critical data is inert and preserved/loss-reported; unknown critical semantics reject. |
| 16.5 registries | **Accepted as governance target** | Release manifest pins exact versions/digests; entries are versioned and archived. |
| 16.6 deprecation | **Modified** | Twelve months is a policy target, not universally safe or currently established. Include import/read-only behavior and security exceptions. |
| 17. Implementation guidance | **Partial** | Retain small, auditable, replaceable components and safe resolvers. Do not present the `V09` repository shape as evidence of implementation. |
| 17.1 order / 17.2 MVP | **Modified** | First implement the 0.4 governed-context path. Add Continuity Observation only after exact target records and evaluation profiles exist; add HIC after privacy/human review. |
| 17.3 storage | **Accepted** | Storage-neutral immutable revisions/history; unknown extension preservation. |
| 17.4 policy profiles | **Deferred / Profile** | Example is informative. Define a safe declarative subset or executable contract with deterministic fixtures. |
| 17.5 resolver | **Accepted and strengthened** | Adopt complete SSRF, redirect, DNS, credential, network, byte/time, sandbox, and audit controls. |
| 17.6 canonicalization | **Accepted** | Use RFC 8785 only where selected and test official vectors; specify signature base exactly. |
| 17.7 package privacy | **Superseded / Folded** | Use the 0.4 request/receipt/minimized package pipeline and security profiles. |
| 17.8 anti-patterns | **Accepted with terminology update** | Strong editorial checklist; replace canonical identity language and add stable-ID leakage, auto-acceptance, and assurance-overclaim. |
| 17.9 reference implementation | **Modified** | Merge with modular 0.4 suite layout and class-specific tests. |
| 18. Conformance | **Rejected as a current conformance claim; Partial as candidate requirements** | No executable `V09` suite validates these classes. Adopt selected assertions into the 0.4 registry/profile suites. |
| 18.1 classes | **Modified** | Keep 0.4 actor-specific classes; add Continuity Observer/Evaluator and Human Interaction Boundary only when executable. |
| 18.2 tests | **Accepted as issue/test seeds** | Non-inheritance, observe-only, source/runtime, HIC, lineage, custody, history, erasure, and extension tests are valuable; rebuild exact fixtures. |
| 18.3 statement | **Accepted** | Exact version/class/profile/test/evidence/date/exceptions are required; no unqualified conformance. |
| 18.4 fixtures | **Accepted as roadmap** | Use synthetic data; add hostile, downgrade, alias, authorization, partial import, circular reference, duplicate ID, and round-trip cases. |
| 19. Examples | **Rejected as normative or validated; Partial as informative scenarios** | Preserve scenarios after rebuilding objects with strict schemas and valid identifiers. Current examples cannot enter the conformance pack unchanged. |
| 19.1 normal observation | **Modified** | Useful profile scenario; no general admissibility claim. |
| 19.2 HIC pause | **Modified** | Explicit pause retained; fear-of-error portability deferred; no raw free text by default. |
| 19.3 stale authority | **Accepted as negative fixture** | Must prove no action and no unauthorized bytes; use external status evidence and receipt semantics. |
| 19.4 artifact degradation | **Accepted / Artifact plus observation profiles** | Reference-only source becoming unavailable is a strong cross-profile case. |
| 19.5 provider conflict | **Accepted with terminology update** | Use accepted context, not canonical context; preserve disagreement and review path. |
| 19.6 agent handoff | **Modified** | Use a new audience package, package-local aliases, no credentials, and separate action authorization. |
| 19.7 pause across runtime | **Modified / HIC profile** | Strong demonstration only after explicit profile, privacy, and authorization tests. |
| 19.8 erasure receipt | **Superseded / Folded** | Use the 0.4 Erasure Status Profile vocabulary/evidence rules. |
| 20. Status and open questions | **Superseded as status; Accepted as review input** | `V09` is not the project maturity baseline. Move unresolved issues into the review register with disposition/owner/evidence/exit criteria. |
| 20.1 maturity | **Rejected** | Conceptual statements may be stable hypotheses, but wire, security, profiles, and conformance are not near-1.0 evidence. |
| 20.2 open questions | **Accepted / Triaged** | Identifier, condition registry, evaluation language, crypto, HIC, third-party, erasure, merge, telemetry, governance, accessibility, and PAM issues remain valid inputs. |
| 20.4 path to 1.0 | **Modified** | Retain two independent implementations, interop, security/privacy review, conformance, governance, and freeze gates; add real remote/offline crypto vectors and live accessible human evaluation. |
| Appendix A normative schema excerpt | **Rejected as normative; Deferred as profile sketch** | Incomplete, permissive, and not synchronized with a schema set/fixtures. Rebuild strict profile schemas under 0.4 companion artifacts. |
| Appendix B event registry | **Deferred to Event Binding** | Retain candidate event meanings, rename/version under governed registry, minimize data, and test gaps/retries/order. |
| Appendix C research basis | **Partial / Informative** | Useful primary-source inventory, but every moving standard and legal claim must be live-verified and pinned for the release. Field observations remain explicitly informative. |
| Appendix D editorial checklist | **Accepted and expanded** | Keep boundary, lineage, portability, human dignity, interoperability, and failure checks; add accepted-state governance, identifier privacy, crypto evidence, executable conformance, and source-of-truth sync. |

## 9. Migration and editorial instructions

1. Do not mechanically merge `V09` sections into `V02` or rename `0.2` to `0.9`.
2. Record `V09` in the issue/review register as a competing architectural proposal with the dispositions above.
3. Preserve the exact durable invariants in a short architecture-decision section of 0.4.
4. Reserve distinct names and namespaces for Core, bindings, domain profiles, security profiles, mappings, and conformance classes.
5. Prohibit a second package object. Runtime presentation remains `context_package`; durable movement uses offline/transfer manifests.
6. Draft Continuity Observation and Human Interaction Boundary as separate `0.1-draft` profile documents/schemas only if the release scope permits complete examples, negative fixtures, privacy/security considerations, conformance assertions, and availability claims.
7. If the profiles cannot be made executable in this release, keep their architectural requirements in the disposition register and roadmap; do not include normative wire objects in Core 0.4.
8. Add a release manifest that pins every normative document, schema, registry, binding, profile, fixture, assertion set, and digest. A cross-component conflict invalidates the affected conformance claim until corrected.
9. Keep Remote Security, offline protection, HIC conformance, and universal aggregate continuity unavailable until their specific profiles and evidence exist.
10. Explain in the changelog that the `0.9-draft` file was an architectural proposal, not a published successor in the OCP wire-version sequence.

## 10. Final recommendation

The two drafts should be reconciled by **composition, not fusion**.

`V02` supplies the stronger, validated semantic center and must remain the foundation of the next authoritative project draft. `V09` contributes a valuable observe-only lens: condition observations, freshness, source/runtime separation, degradation/restoration history, safe resolver behavior, explicit pause/resume boundaries, and a rigorous prohibition on inherited authority. Those ideas strengthen OCP when they are mapped into the existing architecture or published as bounded profiles.

They weaken OCP if they become a second core, a second package family, a universal human-state runtime, a universal admissibility score, or a `0.9` maturity claim without executable evidence.

The recommended outcome is therefore:

> **Open Continuity Protocol 0.4 — Consolidated Editor’s Working Draft**, retaining the nine-record governed-context core; adding no new HIC or condition object to core; classifying Continuity Observation and Human Interaction Boundary as independent `0.1-draft` profiles; and deferring universal aggregate/admissibility, sensitive HIC classes, thread/merge semantics, and all unimplemented cryptographic claims until profiles, vectors, independent implementations, and human/security review exist.
