# Changelog

## 0.4-working-draft — 2026-08-12

This is a breaking consolidation of the 0.2 review draft. It is the current project-authoritative working draft until superseded.

The `0.4` label is used because the wire object model, exact-reference rules, recipient model, package-entry model, proposal binding, offline-manifest construction, schemas, fixtures, and conformance evidence model materially change. A clarification-only `0.2.x` label would hide real incompatibility. This maturity label still denotes an editor's working draft, not a stable release.

### Architecture

- Retained the nine-record governed-context core.
- Classified HTTP, local, authorization, offline, transfer, and event mechanics as bindings.
- Classified conversation/message, artifact/lineage, erasure, continuity observation, and human interaction boundary as profiles.
- Rejected a second continuity core and second package format.
- Added scoped normative-source authority and an assertion-result evidence model.

### Core model

- Added immutable snapshot and live-status reference forms.
- Split one delivery recipient/client instance from all plaintext processing recipients.
- Renamed `assertion_kind` to `epistemic_basis`.
- Replaced authoritative-sounding `kind: instruction` with non-control `category: behavior_preference`.
- Added source-authority versus runtime-source separation.
- Required evidence for signature-verified and credential-proof-verified source states.
- Replaced binary proposal rights with bounded operations and selectors.
- Added a non-circular decision-to-result semantic commitment.
- Limited baseline proposal operations to create and revise. Accepted-context withdrawal now requires a registered operation-specific decision/tombstone profile instead of reusing an accepting-result shape that could not represent withdrawal truthfully.

### Packages and bindings

- Replaced arbitrary package entry content with discriminated layer/disclosure entry branches.
- Narrowed the breaking baseline package surface to embedded accepted context and embedded evidence/artifact metadata only. `accepted_and_disputed`, evidence excerpt/full views, artifact-content views, and `content_ref` delivery now require applicable registered profiles rather than passing through the baseline.
- Defined the small evidence/artifact metadata forms as conservative core package projections with package-local source/artifact, space, and supporting-accepted-item bindings. They are not complete source or Artifact Profile records and carry no verified-trust, custody, preservation, or Artifact Profile-conformance assurance.
- Required a content schema URI, package-local subject/space/item/source/decision references, and explicit untrusted-data treatment.
- Required exactly one content carrier.
- Moved transfer manifest out of core.
- Redesigned the offline manifest around payload members, security members, an exact declared member set, and a non-circular signed view.
- Added standalone HTTP discovery and RFC 9457 Problem Details schemas.

### Profiles

- Added Continuity Observation Profile `0.1-draft` as observe-only evidence with no policy or action effect.
- Added Human Interaction Boundary Profile `0.1-draft` for explicit pause/checkpoint/pacing/clarification/resume signals.
- Preserved existing conversation, artifact, lineage, and erasure profile families as draft profiles.

### Standards and conformance

- Added an exact experimental OCP 0.4 ↔ PAM v1.0 field/lifecycle/cardinality/proof/loss mapping. It remains informative until machine-readable loss/sidecar fixtures and two independent adapters pass.
- Added a current primary-source standards registry.
- Expanded the assertion registry from 54 to 107 entries.
- Added an assertion result for every registered assertion.
- Separated local `partial_evidence` from conformance of an identified implementation; the package claims zero implementation passes.
- Added typed containment and widening vectors, decision-result semantic commitment tests, and package-integrity tamper vectors; the 0.4 correction pass further requires declaration-to-request and full request/receipt/package containment, exact-purpose comparison, order-independent processor sets, and accepted-scope projection coverage.
- Added exact-reference, recipient/processor, entry typing, source verification, proposal bounds, offline construction, continuity, HIB, and HTTP negative cases.

### Explicitly not claimed

- No independent interoperability.
- No deployed security, authorization, parser, deletion, or privacy assurance.
- No working cryptographic package-security profile.
- No standards-body adoption, stable governance, or final license adoption.

## Section-by-section disposition from 0.2

| Original section | Disposition | 0.4 treatment | Normative / compatibility | Primary findings |
|---|---|---|---|---|
| Cover/status and orientation (1–2) | Revised | Uses current project-authoritative working-draft status, precise evidence limits, one-sentence/paragraph/example orientation, and scoped source authority. | Normative status revised; wire unaffected. | OCP-NR-001–005, 112 |
| Abstract, problem, goals, non-goals (3–6) | Revised | Narrows OCP to governed presentation and loss-aware movement; explicitly excludes identity, authorization issuance, execution, universal ontology, and legal assurance. | Normative scope clarified; implementations must not infer excluded authority. | OCP-NR-006–019 |
| Design principles and terminology (7–8) | Revised | Replaces canonical truth language with accepted context; adds exact data/control, revocation/erasure, package-local identity, and fail-closed rules. | Breaking terminology and safety semantics. | OCP-NR-016–028, 048–054 |
| Architecture, roles, trust boundaries, core flow (9–11) | Revised/split | Keeps nine records; formalizes binding/profile/mapping/conformance taxonomy and one-delivery-recipient versus processor roles. | Breaking recipient and reference model. | OCP-NR-009–015, 020–024, 048–061 |
| Core object model (12) | Revised | Adds `snapshotRef`, `liveStatusRef`, `deliveryRecipient`, `processingRecipient`, stronger provenance/verification, and bounded proposal rights as shared structures rather than new records. | Wire-breaking. | OCP-NR-020–036, 048–061 |
| Normative schema rules (13) | Replaced | Pins JSON Schema 2020-12, strict member handling, RFC 8785/I-JSON processing, safe numbers, exact package/decision projections, and schema-catalog behavior. | Wire- and validation-breaking. | OCP-NR-023, 040–044, 097–104 |
| Request and grant lifecycles (14–15) | Revised | Requests remain inert; receipt records a typed, attenuated external/local decision with exact request/declaration and live status. | Wire-breaking; preserves authorization boundary. | OCP-NR-048–061, 065–070 |
| Package lifecycle (16) | Replaced | Binds one delivery instance plus approved processors; uses package-local identifiers/selectors, typed entries, minimization, integrity, and no-action authority. | Major wire/security break. | OCP-NR-026–033, 052–061 |
| Proposal and review lifecycle (17) | Revised | Removes ambiguous `expected_revision`; uses exact target, live grant status, bounded rights, immutable decision, and semantic result commitment. | Wire-breaking. | OCP-NR-034–036, 062–070 |
| Accepted-context and evidence rules (18–19) | Revised | Maintains independent epistemic and review axes; exact decision/source links; evidence-backed trust states; no truth or instruction escalation. | Normative strengthening. | OCP-NR-016–028, 040–044 |
| Conversation/message (20) | Moved | Remains a draft domain profile; imported roles are untrusted labels. | Core reduced; profile compatibility only. | OCP-NR-029–033 |
| Artifact/lineage (21) | Moved/revised | Remains profile work; preserves custody, verification, dependency, rights, and evidence/content permission separation. | Core reduced; profile semantics strengthened. | OCP-NR-029–033, 083–091 |
| Import/adapter (22) | Revised | Raw bytes preserved/quarantined; parsed/mapped/accepted zones explicit; provider-adapter fixture uses 0.4 category/epistemic vocabulary. | Breaking adapter vocabulary and trust behavior. | OCP-NR-040–047, 083–091 |
| Export/round trip (23) | Revised | Exact references, unknown-data preservation, stable transfer identity versus runtime aliases, and explicit loss reports. | Normative strengthening; wire-breaking where references change. | OCP-NR-026–028, 080–091 |
| Transfer (24) | Moved/revised | Core retains export invariants; `transfer_manifest` moves to a Transfer Binding with per-entry outcomes and losses. | Classification and path break. | OCP-NR-010–015, 080–082 |
| Revocation/erasure (25) | Revised/moved | Core defines future-access revocation; qualified erasure evidence remains a profile and never becomes an audit-event deletion proof. | Safer assurance semantics; profile path retained. | OCP-NR-071–073 |
| Security (26) | Replaced | Adds exact reference binding, recipient/processor distinction, parser/import rules, source-verification limits, package projections, archive exact-set rules, and honest crypto availability. | Normative security break. | OCP-NR-048–073, 092–104 |
| Privacy (27) | Revised | Strengthens minimization, alias domains, processor/use/retention disclosure, third-party protection, qualified assurance, and audit privacy. | Normative strengthening. | OCP-NR-025–028, 056–061, 071–073 |
| Third-party/organizational rules (28) | Revised/deferred | Baseline remains conservative; complex authority, minors, households, organizations, coercion, and inheritance require profiles/evidence. | Scope narrowed; no implied authority. | OCP-NR-037–039, 071–073 |
| HTTP binding (29) | Revised | Moves to `bindings/http`; uses OpenAPI 3.1, discovery, RFC 9457, idempotency, ETags/preconditions, live status, and standard errors. | Endpoint/body break. | OCP-NR-074–079 |
| Offline format (30) | Replaced | Separates payload/security members, exact archive set, safe paths, and a non-circular signed projection; real protection remains unavailable. | Major binding break. | OCP-NR-062–064, 080–082 |
| Adjacent standards (31) | Revised | Adds exact pins, a 30-source registry, an exact experimental OCP 0.4 ↔ PAM v1.0 mapping, CRP tracking, and reuse/non-duplication boundaries. Executable loss/sidecar fixtures and independent adapters remain open. | Informative/mapping changes. | OCP-NR-083–091 |
| Versioning (32) | Revised | Wire `0.4`; draft status lives in release metadata; 0.9 is an architectural proposal, not a predecessor wire version. | Breaking version negotiation. | OCP-NR-001–008 |
| Extensions/profiles (33) | Revised | Separates bindings, domain/security profiles, mappings, and conformance; unknown critical semantics fail closed. | Extension handling strengthened. | OCP-NR-009–015, 092–096 |
| Errors (34) | Revised | Uses RFC 9457, stable OCP codes, privacy-safe correlation, precondition/integrity/semantic failures, and enumeration resistance. | HTTP behavior strengthened. | OCP-NR-074–079, 097–104 |
| Conformance classes/assertions (35–36) | Replaced | One hundred seven actor-scoped assertions each receive one result; reference vectors are partial evidence, never implementation passes. | Claim semantics breaking. | OCP-NR-097–104 |
| Reference implementation (37) | Revised | Keeps reference code replaceable and non-authoritative; prioritizes independent implementations and hostile vectors. | Informative. | OCP-NR-106–112 |
| Governance (38) | Revised | Separates project authority from standards maturity and lists unresolved license/namespace/community controls. | Governance posture strengthened. | OCP-NR-001–005, 105–117 |
| Design horizon/roadmap/open questions (39–41) | Revised | Moves speculative work into explicit profiles, experiments, and release gates through 2031. | Informative/deferred. | OCP-NR-037–039, 092–096, 106–117 |
| Complete examples (42) | Replaced | Embeds exact generated copies of all 23 positive fixtures. | Machine-synchronized. | OCP-NR-097–104, 111–115 |
| Normative schemas (43) | Replaced | Embeds exact generated copies of all 27 schemas, including bindings/profiles/conformance schema. | Machine-synchronized and wire-breaking. | OCP-NR-020–104, 111–115 |
| References and glossary (44–45) | Revised | Uses current primary-source pins and one definition per important OCP concept. | Editorial/normative terminology alignment. | OCP-NR-016–019, 083–091, 111–115 |

The decision register supplies the full source, disposition, rationale, impacts, artifact targets, validation requirement, and implementation status for every normalized recommendation.
