# OCP next-release normalized recommendation and decision register

**Register version:** 1.0  
**As of:** 2026-08-12  
**Machine validation:** PASS  
**Decision records:** 117  

This register is the normalized editorial decision source for the OCP 0.4 consolidation. It records project decisions, not standards adoption, deployed behavior, interoperability, legal compliance, security certification, or human acceptance.

The JSON file is the machine-readable authority. This Markdown file is a complete synchronized view generated from it. `normalized_recommendation` states the proposal being dispositioned; for rejected, deferred, or superseded proposals, the rationale and target fields record the retained concern and replacement or exit condition.

Statuses describe editorial implementation in the current source tree, not conformance results. **implemented** means the required source artifact or specification semantics are present and applicable local source checks passed; it does not establish deployed behavior, complete conformance, independent interoperability, security assessment, human acceptance, or final publication. An implemented decision may still have `not_executed`, `manual_required`, `partial_evidence`, or `unavailable` assertions. `executed_pass` is reserved for a named system under test with complete evidence for every required facet.

## Machine-validation result

- Result: **PASS**
- Parsed decisions: **117**
- Unique IDs: **117**
- Sequential range: **OCP-NR-001 through OCP-NR-117**
- Required-field, impact-field, disposition-enum, status-enum, ID-pattern, unique-ID, and conflict-reference errors: **0**

## Disposition summary

| Disposition | Count |
|---|---:|
| Accepted | 74 |
| Modified | 13 |
| Partially Accepted | 2 |
| Rejected | 20 |
| Deferred | 7 |
| Superseded | 1 |

## Status summary

| Status | Count | Meaning |
|---|---:|---|
| implemented | 53 | Required source artifact or specification semantics are present and applicable local source checks passed; no deployment or conformance claim is implied. |
| planned | 36 | One or more required source artifacts, synchronization steps, local source checks, or acceptance gates remain. |
| deferred | 7 | The decision requires a future profile, experiment, authority, or evidence gate. |
| closed | 21 | The rejected or superseded proposal is closed for the 0.4 architecture. |
| blocked | 0 | The decision cannot progress without an external prerequisite. |

## Source coverage

A count is the number of deduplicated decision records citing that source family, not a vote count. The byte-identical process-brief aliases are represented once.

| Source | Decision records | Source description |
|---|---:|---|
| R1 | 48 | pasted-text-1.txt, reconstructed independent review and proposed 0.2 rewrite |
| R2 | 58 | pasted-text-2.txt, reconstructed review containing slim-core and later expanded variants |
| R3 | 23 | pasted-text-3.txt, security/architecture rewrite proposal |
| BRIEF | 29 | pasted-text-4.txt, governing revision brief; pasted-text-5 through 8 are byte-identical aliases |
| B0 | 83 | deliverables/OCP-v0.2-Review-Draft.md |
| P0 | 4 | deliverables/OCP-Schema-and-Conformance-Pack |
| SYN | 37 | root 0.4 synthesis DOCX/XLSX as represented by work/synthesis_extract and package inventory |
| ARCH | 79 | work/next_release_architecture_review.md |
| SEC | 54 | work/next_release_security_review.md |
| V09 | 34 | root v0.9 architectural branch as reconciled in work/v09_reconciliation.md |
| INV | 18 | work/next_release_package_inventory.md |
| LEAD | 19 | independent whole-suite architecture/security/editorial determination for this consolidation |

## Conflict-set index

| Conflict set | Meaning | Decisions |
|---|---|---:|
| CS-CORE-001 | Nine-record governed-context core versus reviewer object-count expansion or a competing continuity core | 20 |
| CS-AUTH-001 | External operation-time authorization plus non-secret receipt versus bearer grants, token claims, or portable authority objects | 14 |
| CS-ID-001 | Stable internal/transfer continuity identifiers versus audience-pairwise and package-local presentation aliases | 3 |
| CS-ENVELOPE-001 | Object-specific/envelope-family design versus one universal resource or message envelope | 3 |
| CS-PACKAGE-001 | Runtime context package versus durable transfer/offline package and the rejected second continuity package | 6 |
| CS-TRANSFER-001 | Transfer as a core invariant with binding mechanics versus a tenth core semantic record | 1 |
| CS-CRYPTO-001 | Evidence-bounded security profiles versus prose-only mandatory algorithms, signatures, encryption, or DPoP claims | 12 |
| CS-IMPORT-001 | Lossless raw quarantine plus safe derivatives versus destructive sanitization or trust-by-signature | 5 |
| CS-EVENT-001 | Reference-first optional event binding versus mandatory CloudEvents as state/audit authority | 2 |
| CS-VERSION-001 | 0.4 working-draft maturity versus 0.9/approved/stable claims without independent evidence | 8 |
| CS-HIC-001 | Explicit human-boundary profile versus inferred human-state runtime or core HIC records | 5 |
| CS-CONT-001 | Bounded continuity observations versus universal aggregate/admissibility/thread state | 6 |
| CS-PROV-001 | Minimal OCP provenance plus mappings versus full PROV/C2PA semantics in every core record | 7 |
| CS-ACCEPT-001 | Independent epistemic and review dimensions in one context item versus separate accepted-claim and interpretation wire types | 3 |
| CS-ERASURE-001 | Qualified revocation/deletion/erasure evidence versus tombstone or event-based proof of purge | 4 |
| CS-GOV-001 | Neutral project-authoritative draft versus proprietary dependency or premature standards posture | 4 |

## Decision index

| ID | Disposition | Status | Target version | Target layer | Normalized recommendation |
|---|---|---|---|---|---|
| OCP-NR-001 | Accepted | planned | 0.4 | editorial | Publish the successor as Open Continuity Protocol 0.4 — Consolidated Editor's Working Draft. |
| OCP-NR-002 | Accepted | planned | 0.4 | governance | Describe 0.4 as the current project-authoritative draft until superseded, and explicitly not an adopted standard, production recommendation, legal conclusion, interoperability result, or security certification. |
| OCP-NR-003 | Accepted | implemented | 0.4 | core serialization | Use wire value ocp_version 0.4 and keep draft status in release metadata rather than embedding draft syntax in the wire version. |
| OCP-NR-004 | Accepted | planned | 0.4 | suite governance | Adopt scoped normative authority: prose owns semantics and actor obligations; schemas own representation; registries own identifiers/transitions; bindings own transport; assertions and fixtures own executable expectations. |
| OCP-NR-005 | Accepted | planned | 0.4 | release engineering | Publish a release manifest that pins every normative document, schema, registry, binding, profile, mapping, fixture, assertion set, unavailable claim, and digest. |
| OCP-NR-006 | Accepted | implemented | 0.4 | architecture | Formalize six distinct suite categories: core semantic records, protocol bindings, domain profiles, security profiles, adjacent-standard mappings, and actor-specific conformance classes. |
| OCP-NR-007 | Accepted | planned | 0.4 | release engineering | Maintain modular text/data sources as editable authority and generate reader DOCX/PDF, workbook, reports, and ZIP derivatives reproducibly. |
| OCP-NR-008 | Accepted | implemented | 0.4 | governance | Require zero proprietary dependency in core; KnowOnce and other products may appear only in clearly informative, replaceable examples or history. |
| OCP-NR-009 | Accepted | implemented | 0.4 | core terminology | Use accepted context for scoped reviewed context and reserve canonical or canonicalization only for deterministic byte representation. |
| OCP-NR-010 | Accepted | implemented | 0.4 | editorial | Retain BCP 14 requirement interpretation, name the obligated actor in each normative statement, and keep examples informative unless explicitly incorporated by an assertion. |
| OCP-NR-011 | Accepted | implemented | 0.4 | review governance | Keep stable architecture decisions and this complete recommendation register, including rejected expansions and their rationale. |
| OCP-NR-012 | Accepted | implemented | 0.4 | review provenance | Record hashes and provenance for R1, R2, R3, the governing brief, 0.2 baseline, synthesis binaries, and v0.9; treat pasted files 5–8 as duplicate aliases rather than independent votes. |
| OCP-NR-013 | Accepted | implemented | 0.4 | editorial | Publish a concise executive summary, full changelog, 0.2-to-0.4 migration guide, glossary, issue/review register, and source-feedback manifest synchronized to the release. |
| OCP-NR-014 | Accepted | planned | pre-1.0 | governance | Define neutral governance, IPR, registry stewardship, security-response, conflict-of-interest, namespace durability, appeal, and change-control targets, while labeling unimplemented governance as roadmap rather than current evidence. |
| OCP-NR-015 | Deferred | deferred | 0.4 or pre-public release | governance | Treat CC BY 4.0 for specification text and Apache-2.0 for code/schemas as a proposal requiring steward/legal adoption, not an automatically effective license decision. |
| OCP-NR-016 | Accepted | implemented | 0.4 | core | Retain exactly nine concrete core records: context_space, source_record, context_item, client_declaration, context_request, grant_receipt, context_package, update_proposal, and review_decision. |
| OCP-NR-017 | Modified | implemented | 0.4 | core and bindings | Keep a reusable record-envelope schema family and object-specific protocol messages; do not create a second universal MessageEnvelope or force native discovery/problem/event/archive objects into one envelope. |
| OCP-NR-018 | Accepted | implemented | 0.4 | core:context_space | Keep context_space as the scope and authority-evaluation boundary; Core Personal conformance remains self-authorized, while organizational, household, guardian, or joint authority requires an explicit profile. |
| OCP-NR-019 | Modified | implemented | 0.4 | core:source_record and provenance | Preserve source authority/origin, capture adapter or runtime source, evaluator, verifier, and recipient as distinct provenance roles; none alone implies truth, acceptance, disclosure authority, or action authority. |
| OCP-NR-020 | Rejected | closed | 0.4 | core:context_item | Split accepted claims and provider interpretations into separate core wire record types. |
| OCP-NR-021 | Modified | implemented | 0.4 | core:context_item and profile:work-context | Replace authoritative-sounding core kind instruction with behavior_preference, or otherwise make the field strictly descriptive and incapable of gaining control-channel priority; move richer goals/decisions/instructions to Work Context Profile. |
| OCP-NR-022 | Accepted | implemented | 0.4 | core:context_item and registries | Retain URI predicates and a typed value model with profile schemas; govern stable identifiers without creating a universal ontology of a person. |
| OCP-NR-023 | Accepted | implemented | 0.4 | core:client_declaration | Keep client_declaration core as a review input describing identity, recipients, retention, training/processing use, security contact, and assurance claims; declarations are claims, not proof of compliance. |
| OCP-NR-024 | Accepted | implemented | 0.4 | core:context_request | Keep context_request as an inert structured request for purpose, selectors/views, audience, time, uses, retention, proposal rights, delegation, and offline use; it is never authority. |
| OCP-NR-025 | Rejected | closed | 0.4 | core:grant_receipt | Remove the native grant_receipt or make an OCP grant/token response the durable bearer-style authorization object. |
| OCP-NR-026 | Accepted | implemented | 0.4 | core:context_package | Keep context_package as immutable, minimized, purpose-, audience-, time-, view-, and receipt-bound runtime presentation whose content is always inert data. |
| OCP-NR-027 | Accepted | implemented | 0.4 | core:update_proposal | Keep update_proposal as an inert client proposal with optimistic concurrency; no client may directly write accepted state. |
| OCP-NR-028 | Accepted | implemented | 0.4 | core:review_decision | Keep immutable review_decision as exact authority and outcome evidence; acceptance creates a new context-item revision linked to the exact proposal, decision, reviewer scope, and resulting digest. |
| OCP-NR-029 | Rejected | closed | 0.4 profile 0.1-draft | profile:artifact-lineage | Make Artifact or ArtifactManifest a core semantic record. |
| OCP-NR-030 | Rejected | closed | profile 0.1-draft | profile:conversation | Make Conversation and Message core semantic records. |
| OCP-NR-031 | Rejected | closed | 0.4 and optional profiles | source/adapter rules | Make InteractionSignal a core semantic record. |
| OCP-NR-032 | Deferred | deferred | future profile | profile:multi-party-authority | Defer a standalone StewardshipRecord and universal guardianship model to Multi-party Authority, Household, Minors, and Organization profiles with legal/human review. |
| OCP-NR-033 | Rejected | closed | 0.4 | binding:discovery | Make CapabilityDocument a persistent core record. |
| OCP-NR-034 | Modified | planned | 0.4 | adapter conformance and profiles | Keep provider mapping and redaction as import-adapter reports, package omission/source state, or profile structures; do not make either a general core record until independent prototypes prove portable lifecycle value. |
| OCP-NR-035 | Rejected | closed | future profile | profile:credential-evidence | Make Credential a core semantic record. |
| OCP-NR-036 | Rejected | closed | profile 0.1-draft or roadmap | profile:erasure-status | Make ErasureRecord a core semantic record or collapse erasure evidence into generic events. |
| OCP-NR-037 | Accepted | planned | future profiles | domain profiles | Keep organization, household, joint, guardian, professional, and other complex domains out of Core Personal and develop separate authority/custody profiles. |
| OCP-NR-038 | Deferred | deferred | future experimental profile | profile:delegation | Keep baseline delegation exactly none and defer agent delegation records/chains to an experimental profile after attenuation and independent authorization prototypes. |
| OCP-NR-039 | Rejected | closed | 0.4 | architecture | Adopt the v0.9 continuity thread, snapshot, condition, authority, HIC, event, and continuity-package family as the successor OCP core. |
| OCP-NR-040 | Modified | planned | 0.4 | core identifiers and transfer binding | Define separate identifier domains for stable provider-internal IDs, scoped transfer/continuity IDs, audience-pairwise aliases, and package-local aliases; preserve semantic mapping, not the same disclosed identifier, across round trips. |
| OCP-NR-041 | Accepted | implemented | 0.4 | core plus bindings | Keep runtime presentation and durable movement as different products: context_package for minimized runtime delivery; offline and transfer manifests for user-directed durable movement; prohibit a second continuity_package. |
| OCP-NR-042 | Accepted | implemented | 0.4 | core common schema | Introduce an exact immutable snapshot reference containing id, revision, schema_uri, and digest for every security-significant cross-record link. |
| OCP-NR-043 | Accepted | implemented | 0.4 | core plus bindings | Define live status references separately from immutable snapshot references and require operation-time checks where current revocation, expiry, or assurance status matters. |
| OCP-NR-044 | Accepted | implemented | 0.4 | core invariant and bindings | Require external or local operation-time authorization for every protected read, issue, dereference, proposal, decision, transfer, and status operation; no OCP request, receipt, signature, package ID, or record ID is authority. |
| OCP-NR-045 | Modified | planned | binding 0.1-draft | binding:oauth-rar | Make OAuth RAR normative only inside a registered remote OAuth/RAR binding; do not require it for local brokers, OS policy, GNAP, or other valid deployments. |
| OCP-NR-046 | Rejected | closed | 0.4 | authorization bindings | Put full OCP grant decisions into access-token claims and use bearer-token semantics for package delivery. |
| OCP-NR-047 | Rejected | closed | 0.4 | binding:http discovery | Merge OCP discovery metadata into OAuth Protected Resource Metadata. |
| OCP-NR-048 | Accepted | implemented | 0.4 | core:request/receipt/package | Replace conflated audience arrays with exactly one delivery recipient and authenticated client-instance binding per runtime package, plus a separately approved set of every plaintext processing recipient. |
| OCP-NR-049 | Accepted | implemented | 0.4 | core terminology and profiles | Define subprocessing as declared plaintext processing without OCP retrieval/proposal/transfer/further-delegation rights; define delegation as authority for an independently acting child principal and keep it disabled in baseline. |
| OCP-NR-050 | Accepted | implemented | 0.4 | core:context_package | Discriminate package entries by layer and disclosure, require content_schema_uri for structured JSON, validate accepted context as context_item, and bind evidence/artifact entries to supported profile schemas. |
| OCP-NR-051 | Accepted | planned | 0.4 | core package rendering and import safety | Require every rendering to declare instruction_treatment untrusted_data, media type, digest, derivation references, and language when known; escape or sandbox active formats. |
| OCP-NR-052 | Accepted | implemented | 0.4 | core invariant | Preserve immutable invariant external_action_authority none: context, evidence, artifacts, accepted items, receipts, signatures, HIC signals, and continuity observations never authorize purchases, messages, publication, deployment, deletion, tools, or other external actions. |
| OCP-NR-053 | Modified | planned | 0.4 | import safety and adapter conformance | Keep raw, parsed, mapped, and accepted import trust zones; quarantine is a state boundary, not automatically a new portable object, and no parsed/mapped item may become accepted without proposal/review. |
| OCP-NR-054 | Rejected | closed | 0.4 | import safety | Sanitize imports by destructively stripping markup, code blocks, instruction-looking text, or signed bytes before further use. |
| OCP-NR-055 | Accepted | planned | 0.4 | core:source_record | Replace unsupported provider_signed and credential_verified labels with signature_verified and credential_proof_verified states that conditionally require exact verification evidence. |
| OCP-NR-056 | Accepted | planned | 0.4 | core serialization | Specify UTF-8 without BOM, reject invalid UTF-8, lone surrogates, duplicate names, non-finite/unsupported values, and use RFC 8785 JCS for digested JSON with an exact omitted-member rule. |
| OCP-NR-057 | Accepted | implemented | 0.4 | core serialization/value model | Constrain JSON number handling to JCS/IEEE-754-compatible values and require canonical string/profile representations for precision-sensitive decimals or integers that cannot round-trip safely. |
| OCP-NR-058 | Accepted | implemented | 0.4 | core:request/receipt/package/proposal | Replace binary proposal_rights with bounded operation, target/create selectors, spaces, predicates/kinds, maximum sensitivity, source/evidence attachment rights, time, client-instance, and local-policy intersection. |
| OCP-NR-059 | Deferred | deferred | future profile | profile:auto-review | Do not permit automatic low-risk acceptance in core; defer any Auto-Review Profile until strict exclusions, reversible audit, rate/bulk controls, trusted policy ownership, and human testing exist. |
| OCP-NR-060 | Accepted | implemented | 0.4 | core decision chain | Bind the exact client-declaration snapshot into request and receipt; require active/unexpired status at issuance/use and suspend approval after material processor, model-provider, retention, training, or deletion-capability change. |
| OCP-NR-061 | Accepted | planned | 0.4 | core identifiers | Require package-local aliases with at least 128 bits of CSPRNG unpredictability or stable pairwise aliases from random mapping or a provider-secret domain-separated PRF including verified audience, instance, version/epoch, and appropriate scope/purpose. |
| OCP-NR-062 | Rejected | closed | security profile 0.1-draft | security profiles | Mandate signatures and named JWS/JWE/age or AES-256-GCM rules in core without a complete registered construction and vectors. |
| OCP-NR-063 | Accepted | implemented | offline security profile 0.1-draft | binding:offline and security profile | Redesign offline protection without signature self-reference: manifest covers ciphertext payload entries; canonical signed view excludes detached signature object; security members are separately declared; physical members equal manifest plus payload plus security sets. |
| OCP-NR-064 | Rejected | closed | 0.4 | security and OAuth binding | Require DPoP for every client and treat it as cryptographic non-forwarding protection for delivered plaintext. |
| OCP-NR-065 | Accepted | planned | 0.4 | binding:offline/import safety | Require exact normalized physical archive-member equality with the manifest and reject hidden/unlisted members, path collisions, local/central header disagreement, symlinks/hardlinks, unsafe paths, trailing ambiguity, excessive nesting, and bombs. |
| OCP-NR-066 | Accepted | planned | 0.4 | security conformance | Add an end-to-end synthetic-secret containment requirement covering sources, proposals, packages, renderings, errors, events, logs, analytics, embeddings, and model input. |
| OCP-NR-067 | Accepted | planned | 0.4 | event/telemetry binding | Prohibit raw entry/content digests, stable aliases, free-text purposes/HIC signals, filenames, relationship IDs, or cross-purpose correlators in general telemetry; use opaque event-local refs or purpose-scoped keyed commitments when justified. |
| OCP-NR-068 | Accepted | implemented | 0.4 | core time semantics and bindings | Define comparison instants, allowed clock skew per binding, future-issued limits, complete cross-field temporal order, stale declaration/evidence handling, and timezone-independent comparison; wall-clock time never resolves write conflicts. |
| OCP-NR-069 | Accepted | planned | 0.4 | privacy and core conformance | Default Core Personal to exclude or quarantine raw third-party and organization-managed content; require relationship-only/coarsened representations or separate authority profiles for broader disclosure. |
| OCP-NR-070 | Accepted | implemented | 0.4 | core privacy plus erasure profile | Keep revocation, retention expiry, deletion request, deletion acknowledgment, provider-reported completion, cryptographic erasure, downstream copies, and independent verification as separate bounded claims. |
| OCP-NR-071 | Rejected | closed | 0.4 | privacy lifecycle | Define tombstoned to prove that underlying record data has been purged. |
| OCP-NR-072 | Rejected | closed | 0.4 | package lifecycle | Treat consumed, retained, or destroyed as authoritative provider-known package lifecycle states. |
| OCP-NR-073 | Deferred | deferred | future security/domain profile | profile:selective-disclosure | Defer SD-JWT, BBS+, or other selective-disclosure systems from core until realistic graph, array, artifact, revocation, and linkability experiments justify a profile. |
| OCP-NR-074 | Accepted | implemented | 0.4 | security invariant | State normatively that valid signature or credential proof establishes only the profile-defined covered bytes and control relationship; it never proves truth, safety, current authority, acceptance, sensitivity, or disclosure rights. |
| OCP-NR-075 | Accepted | implemented | artifact profile 0.1-draft | profile:artifact-lineage | A preserved or managed-copy claim requires an independent readable copy, exact byte digest, size, verification time, custody mode, source-dependency/availability state, and evidence; a source URI or digest alone is insufficient. |
| OCP-NR-076 | Accepted | planned | 0.4 | import and consumer safety | Treat all context and imported carriers—including signed or subject-confirmed JSON keys/values, filenames, URLs, EXIF/OCR, audio transcripts, PDF, code, and nested archives—as untrusted data with zero privileged effects. |
| OCP-NR-077 | Modified | implemented | 0.4 | architecture invariant | OCP observes and presents but does not secretly block or authorize external actions; hosts own and attribute any external policy decision, while OCP may create its own authorized records and audit evidence. |
| OCP-NR-078 | Accepted | planned | binding 0.1-draft | binding:http | Publish a remote HTTP binding with resource URIs, methods, provisional media types, idempotency, ETags, pagination where applicable, exact errors, discovery, and authorization hooks; do not imply IANA registration. |
| OCP-NR-079 | Accepted | planned | binding 0.1-draft | binding:local-broker | Publish a local-broker binding using authenticated local IPC, OS identity/capabilities, explicit app-instance binding, and equivalent consent/containment; localhost or filesystem possession alone is never authority. |
| OCP-NR-080 | Modified | implemented | binding 0.1-draft | binding:offline | Keep offline archive as a binding with safe manifest/serialization semantics; structural offline conformance may ship while cryptographic protection remains unavailable until its security profile executes. |
| OCP-NR-081 | Modified | implemented | binding 0.1-draft | binding:transfer | Keep loss-aware export invariants normative but move transfer_manifest schema/lifecycle to a Transfer Binding required for portable-provider/exporter/importer claims, not the nine-record semantic core. |
| OCP-NR-082 | Rejected | closed | event binding 0.1-draft | binding:events | Require a CloudEvents event for every transition and treat that stream as mandatory audit/state machinery. |
| OCP-NR-083 | Accepted | implemented | 0.4 | binding:http and registries | Use RFC 9457 Problem Details with a governed, namespaced error registry specifying status, retryability, disclosure behavior, and profile-specific extension rules. |
| OCP-NR-084 | Accepted | planned | 0.4 | core lifecycles and bindings | Keep explicit lifecycles, immutable revisions, optimistic concurrency, If-Match/ETags, and principal/endpoint/version/digest-bound idempotency; prohibit direct state jumping and wall-clock conflict resolution. |
| OCP-NR-085 | Accepted | planned | 0.4 | core package and transfer binding | Require partial packages/transfers to distinguish omitted, unavailable, redacted, unauthorized, corrupted, unsupported, and intentionally excluded entries without leaking sensitive existence. |
| OCP-NR-086 | Accepted | planned | 0.4 | core extensibility and transfer | Preserve or loss-report unknown non-critical extension data while keeping it inert and unrendered; reject unknown critical semantics; distinguish semantic JSON preservation from exact opaque-byte preservation. |
| OCP-NR-087 | Accepted | implemented | mapping 0.1-draft | mapping:PAM | Make a field-level, lifecycle-level, cardinality-, proof-, and loss-aware mapping to exact PAM v1.0 the highest-priority adjacent-standard mapping; do not describe PAM as merely early research. |
| OCP-NR-088 | Modified | planned | 0.4 plus mapping | core provenance and mapping:PROV | Use a minimal required OCP provenance model and publish an exact W3C PROV mapping; do not require full PROV Agent/Entity/Activity graphs on every core object. |
| OCP-NR-089 | Accepted | planned | mappings 0.1-draft | mapping:MCP/A2A | Treat MCP and A2A as optional carriage/capability mappings only; OCP must not define agent identity, task execution, tool runtime, or action delegation, and recipients revalidate OCP independently. |
| OCP-NR-090 | Accepted | planned | mappings 0.1-draft | mappings | Publish bounded mappings for C2PA, VC/SD-JWT, and Solid: C2PA proves defined media provenance, credentials prove defined statements/control, and Solid provides storage/access; none supplies accepted context, disclosure authority, truth, or preservation by itself. |
| OCP-NR-091 | Modified | planned | 0.4 and mapping | mapping:privacy and legal considerations | Use DPV and legal/regulatory sources only as optional pinned mappings/informative alignment; do not encode legal conclusions or claim GDPR, Data Act, AI Act, COPPA, or other compliance. |
| OCP-NR-092 | Partially Accepted | implemented | profile 0.1-draft | profile:continuity-observation | If release scope permits executable artifacts, publish Continuity Observation Profile 0.1-draft for immutable, exact-target observations/evaluations with four-valued results, profile/method/version, basis refs, freshness, evaluator, append-only change/restoration links, and no action authority. |
| OCP-NR-093 | Deferred | deferred | future experimental profile | profile:continuity-evaluation | Reject universal admissibility and intact/strained/degraded/broken aggregate states in core; allow only profile-specific non-authoritative evaluation results after independent deterministic evidence. |
| OCP-NR-094 | Partially Accepted | planned | profile 0.1-draft | profile:human-interaction-boundary | If executable and reviewed, publish Human Interaction Boundary Profile 0.1-draft limited to explicit pause, checkpoint, clarification request, slower pacing, and resume controls with expiry, inspect/correct/delete, local-first retention, and no raw free text by default. |
| OCP-NR-095 | Rejected | closed | not in 0.4/profile 0.1 | profile:HIC exclusions | Standardize inferred fear, overload, hesitation, uncertainty, covert sentiment, biometric, keystroke, silence-based, or demographic-proxy states as portable HIC data. |
| OCP-NR-096 | Deferred | deferred | future profile | profile:live-sync/multi-writer | Defer fork/merge, live sync, and multi-writer conflict protocols; retain immutable revisions, optimistic concurrency, and visible conflicts in core. |
| OCP-NR-097 | Accepted | planned | 0.4/profile 0.1 | binding:reference-retrieval/import safety | Require isolated resolvers with scheme/host allowlists, redirect and DNS rechecks, no ambient credentials, network/byte/time/depth bounds, sandboxing, audit minimization, and indeterminate failure rather than permissive fallback. |
| OCP-NR-098 | Accepted | implemented | 0.4 | conformance | Publish one assertion-results entry for every registered assertion with exactly one status: executed_pass, executed_fail, partial_evidence, not_executed, manual_required, unavailable, or not_applicable, plus scoped evidence. executed_pass requires a named system under test and complete evidence for every required facet; reference vectors alone use partial_evidence. |
| OCP-NR-099 | Accepted | implemented | 0.4 | conformance | Retain existing valid assertions and fixtures, add exact-reference, recipient-role, typed-entry, JSON/JCS, crypto-envelope, verification-evidence, proposal, secret, third-party, telemetry, time, archive, and result-accounting cases, and never reduce current negative coverage. |
| OCP-NR-100 | Accepted | planned | 0.4 | conformance tools | Use conformant canonicalization and at least two independent language/validator lanes for strict JSON/JCS vectors and critical cross-record checks. |
| OCP-NR-101 | Accepted | implemented | 0.4 | conformance availability | Keep Remote Security, offline protection, HIC conformance, and any universal continuity aggregate explicitly unavailable until their exact profiles, implementations, vectors, reviews, and evidence exist. |
| OCP-NR-102 | Accepted | implemented | 0.4 | conformance evidence | Treat schema/semantic harness results as local structural evidence only; Import Safety requires deployed sandbox/resource-boundary tests, and remote security requires profile implementations and adversarial review. |
| OCP-NR-103 | Accepted | planned | pre-1.0 | maturity gates | Require at least two independent providers and one independent client, request→receipt→package→proposal→review interop, A→B→A loss-aware round trip, hostile containment, and accessible consent/review evaluation before 1.0 or near-RC claims. |
| OCP-NR-104 | Accepted | implemented | 0.4 | release engineering | Build 0.4 in a new versioned release tree with source spec, core schemas, bindings, profiles, mappings, registries, conformance, examples, review data, tools, and generated dist; do not overwrite 0.2. |
| OCP-NR-105 | Modified | implemented | 0.4 release acceptance | workspace hygiene | After the new release passes acceptance, freeze 0.2, v0.9, synthesis binaries, superseded schema work, and review inputs under explicit historical/archive boundaries; do not delete evidence prematurely. |
| OCP-NR-106 | Accepted | implemented | 0.4 | release packaging | Keep package-lock, require clean npm ci, and exclude node_modules, .DS_Store, __MACOSX, editor locks, render caches, temporary DOCX files, and analysis work from source/release manifests and archives. |
| OCP-NR-107 | Accepted | implemented | 0.4 | release packaging | Produce one deterministic release ZIP with one stable top-level directory, fixed ordering/timestamps, no self-inclusion, a SHA256SUMS file that excludes itself, clean extraction tests, and no Finder-created duplicate. |
| OCP-NR-108 | Superseded | closed | 0.4 | release tools | Use the existing stale work generators and v0.9 builders as the active 0.4 source/build pipeline. |
| OCP-NR-109 | Accepted | implemented | 0.4 | document production | Capture one deterministic Markdown-to-DOCX/PDF build and run OOXML integrity, hyperlinks, headings, code/schema presence, pagination, every-page rendering, contact-sheet/full-resolution visual review, and accessibility QA. |
| OCP-NR-110 | Accepted | implemented | 0.4 | review tooling | Treat JSON/text decision and issue data as authority; generate any XLSX review workbook as a convenience and QA source parity, formulas, validations, tables, filters, freeze panes, widths, wrapping, charts, and rendered sheets. |
| OCP-NR-111 | Accepted | implemented | 0.4 | release validation | Run release-wide checks across prose, schemas, schema URIs, examples, lifecycle/error/event/profile registries, OpenAPI, mappings, assertions, result statuses, migration claims, links, versions, filenames, and manifest hashes; any conflict invalidates the affected claim. |
| OCP-NR-112 | Accepted | planned | 0.4 acceptance | implementation review | Perform an independent developer implementation review against only published artifacts, recording ambiguous requirements, missing behavior, complexity traps, and cross-layer inconsistencies; resolve or explicitly defer every blocker. |
| OCP-NR-113 | Accepted | planned | 0.4 claim enablement/pre-1.0 | security review | Conduct independent adversarial review of selected crypto profiles, archive parser, local/remote binding, reference resolver, consent/recipient-change flow, proposal UI, identifier aliases, import sandbox, and telemetry before enabling affected claims. |
| OCP-NR-114 | Accepted | implemented | 0.4 and pre-1.0 | human-facing conformance | Specify machine-readable consent inputs and accessibility/display obligations, but do not claim informed consent quality until representative human testing covers purpose, recipients, retention, training, evidence/artifact views, changes, bulk proposals, and coercion/dark patterns. |
| OCP-NR-115 | Accepted | planned | 0.4 acceptance | release governance | Do not mark the next release complete merely because files were generated; completion requires demonstrated material improvement, resolved architecture conflicts, synchronized artifacts, passing local validation, explicit unavailable evidence, independent review disposition, and clean authoritative packaging. |
| OCP-NR-116 | Rejected | closed | not permitted for 0.4 | release posture | Publish a reviewer rewrite immediately as approved, secure, independently interoperable, production-ready, or otherwise mature because its prose scorecard and synthetic tests look complete. |
| OCP-NR-117 | Rejected | closed | 0.4 review methodology | review governance | Treat reviewer assertions marked applied, corrected, complete, or validated as authoritative evidence that their reconstructed schemas and architecture should replace the current 0.2 baseline. |

## Detailed decision records

### OCP-NR-001 — Accepted

- **Sources:** ARCH:§2,§6; V09:§8 title/status; INV:§6; BRIEF:Primary Objective
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** Publish the successor as Open Continuity Protocol 0.4 — Consolidated Editor's Working Draft.
- **Disposition:** Accepted
- **Rationale:** The changes are materially breaking but evidence does not support a near-release-candidate 0.9 or stable label.
- **Target version:** 0.4
- **Target layer:** editorial
- **Affected artifacts:** spec title; VERSION; README; release manifest; generated DOCX/PDF
- **Security impact:** Prevents maturity language from being mistaken for security assurance.
- **Privacy impact:** Avoids implying reviewed privacy effectiveness.
- **Interoperability impact:** Makes the implementation target explicit without claiming independent interop.
- **Validation requirement:** All active titles, filenames, manifests, schemas, examples, and generated artifacts use the chosen label consistently.
- **Status:** planned

### OCP-NR-002 — Accepted

- **Sources:** ARCH:§2,§6; BRIEF:Primary Objective; B0:Status
- **Conflict set:** CS-VERSION-001, CS-GOV-001
- **Normalized recommendation:** Describe 0.4 as the current project-authoritative draft until superseded, and explicitly not an adopted standard, production recommendation, legal conclusion, interoperability result, or security certification.
- **Disposition:** Accepted
- **Rationale:** Repository authority and external standards maturity are different claims.
- **Target version:** 0.4
- **Target layer:** governance
- **Affected artifacts:** status section; README; release manifest; executive summary
- **Security impact:** Constrains assurance overclaim.
- **Privacy impact:** Constrains compliance and consent-quality overclaim.
- **Interoperability impact:** Separates local validation from independent implementation evidence.
- **Validation requirement:** Exact evidence-boundary language appears on the first page and in the manifest; no conflicting active status string remains.
- **Status:** planned

### OCP-NR-003 — Accepted

- **Sources:** ARCH:§6.1; INV:§6; SYN:metadata; LEAD:independent determination
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** Use wire value ocp_version 0.4 and keep draft status in release metadata rather than embedding draft syntax in the wire version.
- **Disposition:** Accepted
- **Rationale:** Core semantics and schema references change; a clean numeric wire value avoids mixed 0.4, 0.4-draft, and synthesis identifiers.
- **Target version:** 0.4
- **Target layer:** core serialization
- **Affected artifacts:** common schema; all examples; OpenAPI; fixtures; migration guide
- **Security impact:** Prevents downgrade/version ambiguity.
- **Privacy impact:** Avoids policy selection against inconsistent versions.
- **Interoperability impact:** Provides one comparable wire value.
- **Validation requirement:** Repository-wide version scan and schema validation show no unintended active wire-version variants.
- **Status:** implemented

### OCP-NR-004 — Accepted

- **Sources:** ARCH:§6.2; INV:§6; BRIEF:Cross-Document Validation; V09:§8 status BCP14
- **Conflict set:** None
- **Normalized recommendation:** Adopt scoped normative authority: prose owns semantics and actor obligations; schemas own representation; registries own identifiers/transitions; bindings own transport; assertions and fixtures own executable expectations.
- **Disposition:** Accepted
- **Rationale:** A total precedence order lets one layer silently broaden another; scoped authority makes conflicts release-invalidating.
- **Target version:** 0.4
- **Target layer:** suite governance
- **Affected artifacts:** status section; release manifest; all normative components
- **Security impact:** Prevents schemas or examples from widening authorization.
- **Privacy impact:** Prevents fixture shortcuts from weakening disclosure rules.
- **Interoperability impact:** Gives implementers a deterministic conflict rule.
- **Validation requirement:** Manifest assigns every normative file a role; cross-component conflicts fail release validation.
- **Status:** planned

### OCP-NR-005 — Accepted

- **Sources:** ARCH:§6.2; V09:§9.8; INV:§5-§8; BRIEF:Supporting Artifacts
- **Conflict set:** None
- **Normalized recommendation:** Publish a release manifest that pins every normative document, schema, registry, binding, profile, mapping, fixture, assertion set, unavailable claim, and digest.
- **Disposition:** Accepted
- **Rationale:** The current workspace has multiple plausible authorities and no single reproducible source-of-truth declaration.
- **Target version:** 0.4
- **Target layer:** release engineering
- **Affected artifacts:** RELEASE-MANIFEST.json; dist checksums; validation report
- **Security impact:** Binds reviewed bytes and unavailable security classes.
- **Privacy impact:** Makes privacy-sensitive profile selection auditable.
- **Interoperability impact:** Pins exact implementation inputs.
- **Validation requirement:** Manifest hashes verify from a clean extraction and omit self-referential digest cycles.
- **Status:** planned

### OCP-NR-006 — Accepted

- **Sources:** ARCH:§2,§3.4; SYN:§5.1; V09:§8.12; LEAD:independent determination
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Formalize six distinct suite categories: core semantic records, protocol bindings, domain profiles, security profiles, adjacent-standard mappings, and actor-specific conformance classes.
- **Disposition:** Accepted
- **Rationale:** The current draft uses profile for unrelated optional artifacts and obscures implementation boundaries.
- **Target version:** 0.4
- **Target layer:** architecture
- **Affected artifacts:** spec architecture; directory layout; registries; conformance claims
- **Security impact:** Separates cryptographic claims from semantic core.
- **Privacy impact:** Keeps sensitive domains opt-in and profile-bounded.
- **Interoperability impact:** Defines what partial implementations can claim.
- **Validation requirement:** Every schema and requirement is classified exactly once and conformance dependencies are machine-checkable.
- **Status:** implemented

### OCP-NR-007 — Accepted

- **Sources:** BRIEF:Review as a Whole; ARCH:§6.3; INV:§5; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Maintain modular text/data sources as editable authority and generate reader DOCX/PDF, workbook, reports, and ZIP derivatives reproducibly.
- **Disposition:** Accepted
- **Rationale:** A monolithic binary or 45-section document alone is not a maintainable standards source.
- **Target version:** 0.4
- **Target layer:** release engineering
- **Affected artifacts:** spec sources; tools; dist DOCX/PDF/XLSX/ZIP
- **Security impact:** Reduces unsynchronized normative copies.
- **Privacy impact:** Keeps review decisions traceable.
- **Interoperability impact:** Allows exact machine artifacts to evolve with prose.
- **Validation requirement:** Clean build reproduces derivatives and parity checks compare headings, links, tables, examples, and hashes.
- **Status:** planned

### OCP-NR-008 — Accepted

- **Sources:** R1:P0-03; R2:I-07; B0:§2.3; ARCH:reviewer decisions; SYN:§2.3
- **Conflict set:** CS-GOV-001
- **Normalized recommendation:** Require zero proprietary dependency in core; KnowOnce and other products may appear only in clearly informative, replaceable examples or history.
- **Disposition:** Accepted
- **Rationale:** A vendor-neutral protocol cannot require commercial APIs, identifiers, services, or governance control.
- **Target version:** 0.4
- **Target layer:** governance
- **Affected artifacts:** non-goals; conformance; examples; governance
- **Security impact:** Avoids hidden trust anchors.
- **Privacy impact:** Avoids mandatory commercial data custody.
- **Interoperability impact:** Preserves independent implementability.
- **Validation requirement:** Normative dependency scan and two-implementation design review find no required vendor surface.
- **Status:** implemented

### OCP-NR-009 — Accepted

- **Sources:** R1:§7; R2:Language Review; SYN:§3.2; B0:glossary; ARCH:reviewer decisions
- **Conflict set:** CS-ACCEPT-001
- **Normalized recommendation:** Use accepted context for scoped reviewed context and reserve canonical or canonicalization only for deterministic byte representation.
- **Disposition:** Accepted
- **Rationale:** Canonical context suggests objective truth, identity completeness, or global authority.
- **Target version:** 0.4
- **Target layer:** core terminology
- **Affected artifacts:** glossary; schemas; examples; migration
- **Security impact:** Reduces authority laundering.
- **Privacy impact:** Rejects dossier/identity implication.
- **Interoperability impact:** Gives one stable semantic term.
- **Validation requirement:** Terminology scan leaves canonical only in serialization contexts and historical migration notes.
- **Status:** implemented

### OCP-NR-010 — Accepted

- **Sources:** BRIEF:Standards Language; V09:§8 status; B0:conventions
- **Conflict set:** None
- **Normalized recommendation:** Retain BCP 14 requirement interpretation, name the obligated actor in each normative statement, and keep examples informative unless explicitly incorporated by an assertion.
- **Disposition:** Accepted
- **Rationale:** Actorless MUST statements and example-driven norms are ambiguous for independent implementers.
- **Target version:** 0.4
- **Target layer:** editorial
- **Affected artifacts:** status section; all normative prose; examples
- **Security impact:** Clarifies who enforces each boundary.
- **Privacy impact:** Clarifies disclosure and retention obligations.
- **Interoperability impact:** Makes requirements testable.
- **Validation requirement:** Normative-language lint flags actorless or untestable requirements; examples are labeled and validated.
- **Status:** implemented

### OCP-NR-011 — Accepted

- **Sources:** BRIEF:Track Every Recommendation; ARCH:§6.4 gate 8; SYN:Appendix C; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Keep stable architecture decisions and this complete recommendation register, including rejected expansions and their rationale.
- **Disposition:** Accepted
- **Rationale:** Rejected alternatives otherwise recur without the context that made them unsafe or out of scope.
- **Target version:** 0.4
- **Target layer:** review governance
- **Affected artifacts:** decision register; architecture decisions; changelog
- **Security impact:** Preserves threat-informed rejections.
- **Privacy impact:** Preserves rejected dossier and inference expansions.
- **Interoperability impact:** Makes scope decisions reviewable.
- **Validation requirement:** Every substantive input has at least one normalized decision and every decision has a stable unique ID and disposition.
- **Status:** implemented

### OCP-NR-012 — Accepted

- **Sources:** BRIEF:Review Methodology,Deliverables; INV:§1; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Record hashes and provenance for R1, R2, R3, the governing brief, 0.2 baseline, synthesis binaries, and v0.9; treat pasted files 5–8 as duplicate aliases rather than independent votes.
- **Disposition:** Accepted
- **Rationale:** Duplicate inputs must not inflate consensus and binary synthesis inputs need traceable source status.
- **Target version:** 0.4
- **Target layer:** review provenance
- **Affected artifacts:** source-feedback manifest; release manifest; decision register
- **Security impact:** Prevents provenance ambiguity.
- **Privacy impact:** Avoids untracked reviewer-data reuse.
- **Interoperability impact:** Makes design evidence reproducible.
- **Validation requirement:** Hashes are recomputed at release and duplicate aliases resolve to one canonical source.
- **Status:** implemented

### OCP-NR-013 — Accepted

- **Sources:** BRIEF:Deliverables; INV:§5; SYN:Appendix E
- **Conflict set:** None
- **Normalized recommendation:** Publish a concise executive summary, full changelog, 0.2-to-0.4 migration guide, glossary, issue/review register, and source-feedback manifest synchronized to the release.
- **Disposition:** Accepted
- **Rationale:** Implementers and reviewers need durable change, compatibility, and decision context rather than a clean spec alone.
- **Target version:** 0.4
- **Target layer:** editorial
- **Affected artifacts:** review/*.md; review/*.json; spec glossary
- **Security impact:** Migration notes expose changed security assumptions.
- **Privacy impact:** Surfaces changed disclosure/identifier behavior.
- **Interoperability impact:** Lets 0.2 implementers upgrade deterministically.
- **Validation requirement:** All referenced IDs, field names, versions, and artifact paths resolve and match schemas.
- **Status:** implemented

### OCP-NR-014 — Accepted

- **Sources:** R1:Governance; R2:Governance; B0:§42; V09:§8.14.8; ARCH:release gates
- **Conflict set:** CS-GOV-001
- **Normalized recommendation:** Define neutral governance, IPR, registry stewardship, security-response, conflict-of-interest, namespace durability, appeal, and change-control targets, while labeling unimplemented governance as roadmap rather than current evidence.
- **Disposition:** Accepted
- **Rationale:** Governance credibility is necessary for 1.0 but cannot be created by prose assertion.
- **Target version:** pre-1.0
- **Target layer:** governance
- **Affected artifacts:** governance section; registry policy; security policy; roadmap
- **Security impact:** Creates a vulnerability and registry response path.
- **Privacy impact:** Creates review and appeal mechanisms.
- **Interoperability impact:** Protects stable identifiers and independent participation.
- **Validation requirement:** Named processes, owners, licenses, and public records exist before any stable standards claim.
- **Status:** planned

### OCP-NR-015 — Deferred

- **Sources:** R2:license proposal; LEAD:independent determination
- **Conflict set:** CS-GOV-001
- **Normalized recommendation:** Treat CC BY 4.0 for specification text and Apache-2.0 for code/schemas as a proposal requiring steward/legal adoption, not an automatically effective license decision.
- **Disposition:** Deferred
- **Rationale:** A reviewer cannot grant rights it does not control; licensing requires owner confirmation and explicit files.
- **Target version:** 0.4 or pre-public release
- **Target layer:** governance
- **Affected artifacts:** LICENSE files; README; source headers
- **Security impact:** Clarifies code reuse conditions.
- **Privacy impact:** No direct effect.
- **Interoperability impact:** Open licensing affects adoption but not wire semantics.
- **Validation requirement:** Rights holder approves exact license texts and all third-party notices are audited.
- **Status:** deferred

### OCP-NR-016 — Accepted

- **Sources:** ARCH:§2,§3.2; SYN:§5.1; B0:§9.4; R1:small-core proposals; R2:small-core proposals
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Retain exactly nine concrete core records: context_space, source_record, context_item, client_declaration, context_request, grant_receipt, context_package, update_proposal, and review_decision.
- **Disposition:** Accepted
- **Rationale:** Each record carries an invariant required by every governed-context exchange; reviewer expansions mix domain profiles, bindings, and implementation concerns into core.
- **Target version:** 0.4
- **Target layer:** core
- **Affected artifacts:** core schema inventory; spec object model; examples; conformance
- **Security impact:** Keeps authority and review records explicit without adding risky domains.
- **Privacy impact:** Limits dossier growth.
- **Interoperability impact:** Stabilizes a bounded implementation target.
- **Validation requirement:** Schema inventory and prose enumerate the same nine records and no profile/binding manifest is labeled core.
- **Status:** implemented

### OCP-NR-017 — Modified

- **Sources:** R2:Resource/Message envelope proposal; R3:envelope proposal; B0:common schema; ARCH:§3.2; SEC:§2
- **Conflict set:** CS-ENVELOPE-001
- **Normalized recommendation:** Keep a reusable record-envelope schema family and object-specific protocol messages; do not create a second universal MessageEnvelope or force native discovery/problem/event/archive objects into one envelope.
- **Disposition:** Modified
- **Rationale:** Persistent records share revision metadata, while native protocol artifacts have different semantics; a universal message envelope adds irrelevant fields.
- **Target version:** 0.4
- **Target layer:** core and bindings
- **Affected artifacts:** common schema; object schemas; problem schema; event binding; archive manifest
- **Security impact:** Avoids trusting irrelevant envelope fields.
- **Privacy impact:** Avoids mandatory metadata leakage.
- **Interoperability impact:** Uses fit-for-purpose native envelopes.
- **Validation requirement:** Every artifact validates against its assigned family and no conflicting universal-envelope requirement remains.
- **Status:** implemented

### OCP-NR-018 — Accepted

- **Sources:** B0:context_space; SYN:§4; ARCH:§3.2; R2:multi-party proposals
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Keep context_space as the scope and authority-evaluation boundary; Core Personal conformance remains self-authorized, while organizational, household, guardian, or joint authority requires an explicit profile.
- **Disposition:** Accepted
- **Rationale:** One universal authority model cannot safely cover persons, employers, children, households, and joint work.
- **Target version:** 0.4
- **Target layer:** core:context_space
- **Affected artifacts:** context-space schema; authority profiles; conformance
- **Security impact:** Prevents blanket steward authority.
- **Privacy impact:** Protects third parties and vulnerable subjects.
- **Interoperability impact:** Keeps core authority deterministic.
- **Validation requirement:** Core Personal fixtures reject non-self authority models unless a supported profile is declared.
- **Status:** implemented

### OCP-NR-019 — Modified

- **Sources:** V09:source_authority/runtime_source; B0:source_record; ARCH:§3.2; SEC:SECDELTA-006
- **Conflict set:** CS-PROV-001
- **Normalized recommendation:** Preserve source authority/origin, capture adapter or runtime source, evaluator, verifier, and recipient as distinct provenance roles; none alone implies truth, acceptance, disclosure authority, or action authority.
- **Disposition:** Modified
- **Rationale:** The v0.9 distinction is valuable but should extend the existing source/provenance model rather than create a parallel core.
- **Target version:** 0.4
- **Target layer:** core:source_record and provenance
- **Affected artifacts:** source-record schema; common reference types; glossary; fixtures
- **Security impact:** Blocks source/authority laundering.
- **Privacy impact:** Makes capture and processing roles visible.
- **Interoperability impact:** Normalizes provenance roles across adapters.
- **Validation requirement:** Fixtures demonstrate independent source, capturer, evaluator, verifier, and recipient identities without inferred authority.
- **Status:** implemented

### OCP-NR-020 — Rejected

- **Sources:** R2:variant A — AcceptedClaim/InterpretationRecord; B0:context_item; ARCH:§3.2; SYN:§3.3,§5.4
- **Conflict set:** CS-ACCEPT-001
- **Normalized recommendation:** Split accepted claims and provider interpretations into separate core wire record types.
- **Disposition:** Rejected
- **Rationale:** Separate accepted-claim and interpretation wire types duplicate records and conflate origin with governance outcome.
- **Target version:** 0.4
- **Target layer:** core:context_item
- **Affected artifacts:** context-item schema; migration; review fixtures
- **Security impact:** Preserves origin after acceptance.
- **Privacy impact:** Keeps provider inference visibly distinct.
- **Interoperability impact:** Avoids object conversion ambiguity.
- **Validation requirement:** Combination-matrix tests prove accepted provider interpretations retain their epistemic basis and require a decision snapshot.
- **Status:** closed

### OCP-NR-021 — Modified

- **Sources:** B0:context_item kind; ARCH:§3.2; SEC:SECDELTA-013; SYN:accepted context
- **Conflict set:** None
- **Normalized recommendation:** Replace authoritative-sounding core kind instruction with behavior_preference, or otherwise make the field strictly descriptive and incapable of gaining control-channel priority; move richer goals/decisions/instructions to Work Context Profile.
- **Disposition:** Modified
- **Rationale:** An accepted instruction label invites instruction laundering into system or developer prompts.
- **Target version:** 0.4
- **Target layer:** core:context_item and profile:work-context
- **Affected artifacts:** context-item schema; migration; hostile fixtures; work profile
- **Security impact:** Closes an instruction-laundering path.
- **Privacy impact:** Keeps behavioral context scoped.
- **Interoperability impact:** Separates generic statements from domain semantics.
- **Validation requirement:** Accepted hostile behavior-preference fixtures remain inert in policy/tool channels.
- **Status:** implemented

### OCP-NR-022 — Accepted

- **Sources:** R1:typed values; R2:typed values; B0:statement model; SYN:§5.5; ARCH:reviewer decisions
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Retain URI predicates and a typed value model with profile schemas; govern stable identifiers without creating a universal ontology of a person.
- **Disposition:** Accepted
- **Rationale:** Opaque free text is not interoperable, but a universal person ontology would be a privacy and adoption failure.
- **Target version:** 0.4
- **Target layer:** core:context_item and registries
- **Affected artifacts:** common schema; predicate registry; profiles; examples
- **Security impact:** Reduces parser ambiguity.
- **Privacy impact:** Avoids compulsory dossier taxonomy.
- **Interoperability impact:** Provides deterministic typed values.
- **Validation requirement:** Each typed value validates against a declared schema and unknown critical semantics fail closed.
- **Status:** implemented

### OCP-NR-023 — Accepted

- **Sources:** R1:ClientDeclaration; R2:ClientDeclaration; B0:client_declaration; SYN:§4.2; SEC:SECDELTA-010
- **Conflict set:** None
- **Normalized recommendation:** Keep client_declaration core as a review input describing identity, recipients, retention, training/processing use, security contact, and assurance claims; declarations are claims, not proof of compliance.
- **Disposition:** Accepted
- **Rationale:** Meaningful consent requires the exact declared behavior while avoiding false attestation semantics.
- **Target version:** 0.4
- **Target layer:** core:client_declaration
- **Affected artifacts:** client-declaration schema; request/receipt chain; consent UI assertions
- **Security impact:** Makes processors and security contacts reviewable.
- **Privacy impact:** Exposes retention/training/subprocessing changes.
- **Interoperability impact:** Standardizes consent inputs.
- **Validation requirement:** Exact declaration snapshots are bound through request and receipt; assurance language distinguishes self-claim from external evidence.
- **Status:** implemented

### OCP-NR-024 — Accepted

- **Sources:** B0:context_request; SYN:§6.1; ARCH:invariants; R1:request flow; R2:request flow
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Keep context_request as an inert structured request for purpose, selectors/views, audience, time, uses, retention, proposal rights, delegation, and offline use; it is never authority.
- **Disposition:** Accepted
- **Rationale:** The semantic request must work across OAuth/RAR, GNAP, local brokers, and offline review without becoming a credential.
- **Target version:** 0.4
- **Target layer:** core:context_request
- **Affected artifacts:** context-request schema; bindings; fixtures
- **Security impact:** Prevents request-as-grant confusion.
- **Privacy impact:** Makes requested disclosure explicit.
- **Interoperability impact:** Allows multiple authorization bindings.
- **Validation requirement:** Fixtures prove possession or replay of a request yields zero access absent current external authorization.
- **Status:** implemented

### OCP-NR-025 — Rejected

- **Sources:** R1:token-response reference; R2:remove native grant; R3:remove native grant; B0:grant_receipt; ARCH:reviewer decisions; SEC:§2
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Remove the native grant_receipt or make an OCP grant/token response the durable bearer-style authorization object.
- **Disposition:** Rejected
- **Rationale:** Removing the receipt loses auditable OCP decision semantics, while making it a token duplicates authorization and creates bearer risk.
- **Target version:** 0.4
- **Target layer:** core:grant_receipt
- **Affected artifacts:** grant-receipt schema; authorization bindings; security assertions; migration
- **Security impact:** Separates evidence from capability.
- **Privacy impact:** Keeps rich context decisions out of bearer tokens.
- **Interoperability impact:** Supports external authorization families consistently.
- **Validation requirement:** Negative tests show receipt/request/package IDs cannot authorize any protected operation.
- **Status:** closed

### OCP-NR-026 — Accepted

- **Sources:** B0:context_package; SYN:§6.3; ARCH:invariants; SEC:SECDELTA-003
- **Conflict set:** CS-PACKAGE-001
- **Normalized recommendation:** Keep context_package as immutable, minimized, purpose-, audience-, time-, view-, and receipt-bound runtime presentation whose content is always inert data.
- **Disposition:** Accepted
- **Rationale:** Runtime presentation is the core exchange product and must not inherit transfer/archive or action semantics.
- **Target version:** 0.4
- **Target layer:** core:context_package
- **Affected artifacts:** context-package schema; package fixtures; consumer assertions
- **Security impact:** Enforces containment and no action authority.
- **Privacy impact:** Enforces minimization and view separation.
- **Interoperability impact:** Defines a stable runtime payload.
- **Validation requirement:** Cross-object containment, expiry, alias, schema, and inert-consumption fixtures pass.
- **Status:** implemented

### OCP-NR-027 — Accepted

- **Sources:** R1:proposal/review; R2:proposal/review; B0:update_proposal; SYN:§6.4; ARCH:invariants
- **Conflict set:** None
- **Normalized recommendation:** Keep update_proposal as an inert client proposal with optimistic concurrency; no client may directly write accepted state.
- **Disposition:** Accepted
- **Rationale:** Proposal/review is the load-bearing boundary preventing provider memory from silently becoming portable truth.
- **Target version:** 0.4
- **Target layer:** core:update_proposal
- **Affected artifacts:** update-proposal schema; HTTP binding; proposal assertions
- **Security impact:** Prevents silent privilege escalation into accepted state.
- **Privacy impact:** Requires visible review of new personal context.
- **Interoperability impact:** Standardizes a safe write path.
- **Validation requirement:** Direct-write, stale-target, cross-space, and silent-timeout fixtures leave accepted state unchanged.
- **Status:** implemented

### OCP-NR-028 — Accepted

- **Sources:** B0:review_decision; SYN:§6.4; ARCH:core; SEC:SECDELTA-009
- **Conflict set:** None
- **Normalized recommendation:** Keep immutable review_decision as exact authority and outcome evidence; acceptance creates a new context-item revision linked to the exact proposal, decision, reviewer scope, and resulting digest.
- **Disposition:** Accepted
- **Rationale:** A mutable status flag cannot prove who accepted which bytes under what scope.
- **Target version:** 0.4
- **Target layer:** core:review_decision
- **Affected artifacts:** review-decision schema; context-item schema; semantic validator
- **Security impact:** Binds accepted state to reviewer authority.
- **Privacy impact:** Makes acceptance scope inspectable.
- **Interoperability impact:** Defines deterministic state transition evidence.
- **Validation requirement:** Dangling, mismatched, non-accept, out-of-scope, and wrong-result decision fixtures fail.
- **Status:** implemented

### OCP-NR-029 — Rejected

- **Sources:** R1:Artifact core; R2:variant B — Artifact core; B0:Artifact Profile; ARCH:§3.3; SYN:§8.2
- **Conflict set:** CS-CORE-001, CS-PROV-001
- **Normalized recommendation:** Make Artifact or ArtifactManifest a core semantic record.
- **Disposition:** Rejected
- **Rationale:** Custody, media, representations, preservation, and C2PA semantics are substantial domain behavior not required by every core exchange.
- **Target version:** 0.4 profile 0.1-draft
- **Target layer:** profile:artifact-lineage
- **Affected artifacts:** profile schemas; core reference types; examples; mapping:C2PA
- **Security impact:** Avoids generic unverified preservation claims.
- **Privacy impact:** Keeps raw artifact disclosure separately permissioned.
- **Interoperability impact:** Allows complete profile semantics without bloating core.
- **Validation requirement:** Profile has custody, digest, availability, source-dependency, stale-verification, and byte-mismatch fixtures.
- **Status:** closed

### OCP-NR-030 — Rejected

- **Sources:** R2:variant B — Conversation/Message core; B0:Conversation Profile; ARCH:§3.3; SYN:§8.3
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Make Conversation and Message core semantic records.
- **Disposition:** Rejected
- **Rationale:** Conversation structure is important portability data but not required in every context exchange and varies by provider.
- **Target version:** profile 0.1-draft
- **Target layer:** profile:conversation
- **Affected artifacts:** conversation/message schemas; fixtures; transfer mapping
- **Security impact:** Prevents imported role labels becoming control roles.
- **Privacy impact:** Keeps raw conversation separately permissioned.
- **Interoperability impact:** Provides a bounded graph profile.
- **Validation requirement:** Branch and attachment round trips either preserve structure or produce deterministic loss reports.
- **Status:** closed

### OCP-NR-031 — Rejected

- **Sources:** R1:InteractionSignal core; R2:profile; V09:HIC; ARCH:§3.3
- **Conflict set:** CS-CORE-001, CS-HIC-001
- **Normalized recommendation:** Make InteractionSignal a core semantic record.
- **Disposition:** Rejected
- **Rationale:** Telemetry is not inherently portable context and can become covert behavioral profiling.
- **Target version:** 0.4 and optional profiles
- **Target layer:** source/adapter rules
- **Affected artifacts:** source schemas; HIC profile; import fixtures
- **Security impact:** Blocks telemetry-to-authority escalation.
- **Privacy impact:** Reduces covert profiling.
- **Interoperability impact:** Keeps interaction semantics profile-scoped.
- **Validation requirement:** Fixtures prove raw interaction events never auto-create accepted preferences.
- **Status:** closed

### OCP-NR-032 — Deferred

- **Sources:** R2:StewardshipRecord; R1:multi-party/minors; B0:authority boundaries; ARCH:§3.3
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Defer a standalone StewardshipRecord and universal guardianship model to Multi-party Authority, Household, Minors, and Organization profiles with legal/human review.
- **Disposition:** Deferred
- **Rationale:** Authority is jurisdictional, temporal, contested, and scope-bound; a universal portable record could enable coercion.
- **Target version:** future profile
- **Target layer:** profile:multi-party-authority
- **Affected artifacts:** profile schemas; governance; safety fixtures
- **Security impact:** Avoids portable blanket-control objects.
- **Privacy impact:** Protects minors, dependents, partners, and joint subjects.
- **Interoperability impact:** Defers semantics until independently implementable.
- **Validation requirement:** Requires legal/safety review, competing-authority fixtures, revocation/aging-out rules, and at least two prototypes.
- **Status:** deferred

### OCP-NR-033 — Rejected

- **Sources:** R2:CapabilityDocument; ARCH:§3.3; B0:discovery
- **Conflict set:** CS-CORE-001, CS-ENVELOPE-001
- **Normalized recommendation:** Make CapabilityDocument a persistent core record.
- **Disposition:** Rejected
- **Rationale:** Capabilities are live deployment metadata, not durable personal context.
- **Target version:** 0.4
- **Target layer:** binding:discovery
- **Affected artifacts:** discovery schema; HTTP/local bindings
- **Security impact:** Keeps live capability status distinct from signed records.
- **Privacy impact:** Avoids unnecessary persistent client metadata.
- **Interoperability impact:** Uses a dedicated negotiation surface.
- **Validation requirement:** Discovery spoofing, stale capability, unsupported critical profile, and issuer/resource mismatch tests pass.
- **Status:** closed

### OCP-NR-034 — Modified

- **Sources:** R2:ProviderMapping/RedactionRecord; B0:adapter fixture/omissions; ARCH:§3.3
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Keep provider mapping and redaction as import-adapter reports, package omission/source state, or profile structures; do not make either a general core record until independent prototypes prove portable lifecycle value.
- **Disposition:** Modified
- **Rationale:** The concerns are real but standalone core records would standardize implementation detail prematurely.
- **Target version:** 0.4
- **Target layer:** adapter conformance and profiles
- **Affected artifacts:** adapter fixture schema; loss report; omission registry
- **Security impact:** Keeps mappings auditable and inert.
- **Privacy impact:** Makes redaction/omission visible without overexposing rules.
- **Interoperability impact:** Supports loss-aware adapters.
- **Validation requirement:** Adapter fixtures report mapped, unmapped, redacted, unsupported, and lossy fields deterministically.
- **Status:** planned

### OCP-NR-035 — Rejected

- **Sources:** R1:Credential objects; R2:Credential objects; B0:Credential Profile roadmap; ARCH:§3.3; V09:§8.12.6
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Make Credential a core semantic record.
- **Disposition:** Rejected
- **Rationale:** Credential formats already exist and proof validity must not become accepted truth or action permission.
- **Target version:** future profile
- **Target layer:** profile:credential-evidence
- **Affected artifacts:** profile schema; mapping:VC/SD-JWT; fixtures
- **Security impact:** Prevents credential proof from granting OCP or domain authority.
- **Privacy impact:** Allows selective disclosure research without core linkability.
- **Interoperability impact:** Composes with existing credential ecosystems.
- **Validation requirement:** Profile tests proof/status/issuer/acceptance/action independence and linkability limits.
- **Status:** closed

### OCP-NR-036 — Rejected

- **Sources:** R1:ErasureRecord core; R2:ErasureRecord core; B0:Erasure Status Profile; ARCH:§3.3; SEC:§2
- **Conflict set:** CS-ERASURE-001, CS-CORE-001
- **Normalized recommendation:** Make ErasureRecord a core semantic record or collapse erasure evidence into generic events.
- **Disposition:** Rejected
- **Rationale:** Revocation and deletion assurance have different actors, evidence, exclusions, and verification levels.
- **Target version:** profile 0.1-draft or roadmap
- **Target layer:** profile:erasure-status
- **Affected artifacts:** erasure schema; privacy section; events
- **Security impact:** Avoids deletion-as-authorization confusion.
- **Privacy impact:** Prevents false proof-of-erasure claims.
- **Interoperability impact:** Defines qualified evidence separately.
- **Validation requirement:** Fixtures distinguish requested, acknowledged, provider-reported, partial, rejected, cryptographic, and independently verified states.
- **Status:** closed

### OCP-NR-037 — Accepted

- **Sources:** R1:organization/household; R2:organization/household; SYN:§5.2; ARCH:§3.3; B0:boundaries
- **Conflict set:** CS-CORE-001
- **Normalized recommendation:** Keep organization, household, joint, guardian, professional, and other complex domains out of Core Personal and develop separate authority/custody profiles.
- **Disposition:** Accepted
- **Rationale:** A person described by data may not own or control employer, customer, household, or third-party data.
- **Target version:** future profiles
- **Target layer:** domain profiles
- **Affected artifacts:** organization profile; multi-party profile; work profile; privacy fixtures
- **Security impact:** Supports DLP and competing authority.
- **Privacy impact:** Prevents one-subject disclosure assumptions.
- **Interoperability impact:** Keeps personal core deterministic.
- **Validation requirement:** Core Personal rejects profile-required authority/custody cases with non-disclosing errors.
- **Status:** planned

### OCP-NR-038 — Deferred

- **Sources:** R1:AgentDelegationRecord; R2:AgentDelegationRecord; B0:delegation none; ARCH:§3.3; SYN:§8.5
- **Conflict set:** CS-CORE-001, CS-AUTH-001
- **Normalized recommendation:** Keep baseline delegation exactly none and defer agent delegation records/chains to an experimental profile after attenuation and independent authorization prototypes.
- **Disposition:** Deferred
- **Rationale:** Context access is not agent action authority; portable delegation chains create escalation and linkability risk.
- **Target version:** future experimental profile
- **Target layer:** profile:delegation
- **Affected artifacts:** request/receipt/package schemas; agent mappings; fixtures
- **Security impact:** Prevents delegated authority escalation.
- **Privacy impact:** Avoids uncontrolled forwarding and child dossiers.
- **Interoperability impact:** Defers complex attenuation semantics.
- **Validation requirement:** Requires child receipts, audience-bound packages, no credential forwarding, revocation, chain audit, and two independent prototypes.
- **Status:** deferred

### OCP-NR-039 — Rejected

- **Sources:** V09:ContinuityThread/Snapshot/ConditionObservation; ARCH:§3.3; V09:reconciliation — §4,§8
- **Conflict set:** CS-CORE-001, CS-CONT-001, CS-HIC-001, CS-PACKAGE-001
- **Normalized recommendation:** Adopt the v0.9 continuity thread, snapshot, condition, authority, HIC, event, and continuity-package family as the successor OCP core.
- **Disposition:** Rejected
- **Rationale:** The v0.9 branch is composable design input, not a validated successor to the stronger nine-record core.
- **Target version:** 0.4
- **Target layer:** architecture
- **Affected artifacts:** core inventory; continuity profile; HIC profile; event binding; migration
- **Security impact:** Preserves existing authorization and no-action boundaries.
- **Privacy impact:** Prevents sensitive human-state expansion.
- **Interoperability impact:** Avoids two incompatible OCP cores.
- **Validation requirement:** No v0.9 core schema URI or second package family appears in active 0.4 core; migration records explicit dispositions.
- **Status:** closed

### OCP-NR-040 — Modified

- **Sources:** R1:round-trip ID preservation; R2:round-trip ID preservation; B0:package-local aliases; ARCH:§5.5; SEC:SECDELTA-011
- **Conflict set:** CS-ID-001
- **Normalized recommendation:** Define separate identifier domains for stable provider-internal IDs, scoped transfer/continuity IDs, audience-pairwise aliases, and package-local aliases; preserve semantic mapping, not the same disclosed identifier, across round trips.
- **Disposition:** Modified
- **Rationale:** Stable IDs aid transfer but become correlation handles when disclosed at runtime.
- **Target version:** 0.4
- **Target layer:** core identifiers and transfer binding
- **Affected artifacts:** common schema; package/transfer schemas; migration; alias fixtures
- **Security impact:** Prevents ID substitution and cross-domain confusion.
- **Privacy impact:** Reduces cross-recipient correlation.
- **Interoperability impact:** Defines how continuity survives alias rewriting.
- **Validation requirement:** A→B→A fixtures preserve semantic mapping and loss reports while runtime aliases differ across audiences/packages.
- **Status:** planned

### OCP-NR-041 — Accepted

- **Sources:** ARCH:invariant 5; V09:ContinuityPackage; B0:context_package/offline/transfer; SYN:§4.1
- **Conflict set:** CS-PACKAGE-001
- **Normalized recommendation:** Keep runtime presentation and durable movement as different products: context_package for minimized runtime delivery; offline and transfer manifests for user-directed durable movement; prohibit a second continuity_package.
- **Disposition:** Accepted
- **Rationale:** Runtime privacy aliases, retention, authorization, and content differ materially from full transfer/archive semantics.
- **Target version:** 0.4
- **Target layer:** core plus bindings
- **Affected artifacts:** context-package schema; offline binding; transfer binding; glossary
- **Security impact:** Prevents archive semantics from weakening runtime containment.
- **Privacy impact:** Avoids dossier-scale runtime packages.
- **Interoperability impact:** Gives each package family one purpose.
- **Validation requirement:** Schemas and terminology contain no semantic collision; conformance classes declare the implemented package family.
- **Status:** implemented

### OCP-NR-042 — Accepted

- **Sources:** SEC:SECDELTA-001; ARCH:release gate 4; B0:revision model; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Introduce an exact immutable snapshot reference containing id, revision, schema_uri, and digest for every security-significant cross-record link.
- **Disposition:** Accepted
- **Rationale:** URI-only references float across revisions and permit same-ID substitution after review.
- **Target version:** 0.4
- **Target layer:** core common schema
- **Affected artifacts:** common reference schema; request; declaration; receipt; package; proposal; decision; source provenance
- **Security impact:** Binds reviewed bytes and semantics.
- **Privacy impact:** Prevents consent from drifting to a broader revision.
- **Interoperability impact:** Makes reference resolution deterministic.
- **Validation requirement:** Wrong revision, digest, schema, or purpose under the same ID fails before authorization or disclosure.
- **Status:** implemented

### OCP-NR-043 — Accepted

- **Sources:** SEC:§4.1; B0:revocation/status; LEAD:independent determination
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Define live status references separately from immutable snapshot references and require operation-time checks where current revocation, expiry, or assurance status matters.
- **Disposition:** Accepted
- **Rationale:** Immutable evidence cannot prove present authorization or key/declaration status.
- **Target version:** 0.4
- **Target layer:** core plus bindings
- **Affected artifacts:** common reference schema; receipt/package bindings; status endpoints
- **Security impact:** Supports revocation and freshness.
- **Privacy impact:** Stops use after material recipient/declaration change.
- **Interoperability impact:** Separates historical semantics from live enforcement.
- **Validation requirement:** Active snapshot plus revoked/stale live status fails with zero content release.
- **Status:** implemented

### OCP-NR-044 — Accepted

- **Sources:** B0:authorization containment; ARCH:invariant 4; SEC:§1; R1:auth proposals; R2:auth proposals; R3:auth proposals
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Require external or local operation-time authorization for every protected read, issue, dereference, proposal, decision, transfer, and status operation; no OCP request, receipt, signature, package ID, or record ID is authority.
- **Disposition:** Accepted
- **Rationale:** Evidence and visibility must never become capabilities.
- **Target version:** 0.4
- **Target layer:** core invariant and bindings
- **Affected artifacts:** security section; HTTP/local bindings; all operation assertions
- **Security impact:** Prevents BOLA and bearer-by-ID behavior.
- **Privacy impact:** Enforces purpose- and recipient-bound access.
- **Interoperability impact:** Allows any conforming authorization layer.
- **Validation requirement:** ID-only, receipt-only, signed-object-only, stale-token, wrong-resource, and wrong-instance cases yield zero bytes/effects.
- **Status:** implemented

### OCP-NR-045 — Modified

- **Sources:** R1:OAuth/RAR fully reuse; R2:RAR mandatory; R3:RAR mandatory; B0:authorization bindings; SEC:§2
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Make OAuth RAR normative only inside a registered remote OAuth/RAR binding; do not require it for local brokers, OS policy, GNAP, or other valid deployments.
- **Disposition:** Modified
- **Rationale:** RAR is a useful carrier, not the OCP semantic state model or universal authorization mechanism.
- **Target version:** binding 0.1-draft
- **Target layer:** binding:oauth-rar
- **Affected artifacts:** RAR mapping; HTTP binding; fixtures
- **Security impact:** Requires typed containment and prevents authorization-details comparison shortcuts.
- **Privacy impact:** Keeps rich request details out of deployments that do not need OAuth.
- **Interoperability impact:** Supports remote OAuth without excluding local-first systems.
- **Validation requirement:** Binding vectors cover partial approval, exact resource/client instance, typed comparison, revocation, and unknown critical details.
- **Status:** planned

### OCP-NR-046 — Rejected

- **Sources:** R3:access-token claims; R1:package bearer token; SEC:§2; ARCH:§5.4
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Put full OCP grant decisions into access-token claims and use bearer-token semantics for package delivery.
- **Disposition:** Rejected
- **Rationale:** Privacy-rich tokens become dossiers, are hard to revoke precisely, and encourage authorization by field presence.
- **Target version:** 0.4
- **Target layer:** authorization bindings
- **Affected artifacts:** OAuth/RAR binding; security guidance; fixtures
- **Security impact:** Reduces token replay and semantic confusion.
- **Privacy impact:** Keeps detailed selectors and recipients out of portable tokens.
- **Interoperability impact:** Avoids coupling core to one token format.
- **Validation requirement:** No example embeds full receipt semantics or raw bearer credentials; token claims alone never pass containment.
- **Status:** closed

### OCP-NR-047 — Rejected

- **Sources:** R3:merge discovery into PRM; R2:PRM alignment; B0:well-known discovery; SEC:§2
- **Conflict set:** CS-ENVELOPE-001
- **Normalized recommendation:** Merge OCP discovery metadata into OAuth Protected Resource Metadata.
- **Disposition:** Rejected
- **Rationale:** PRM has its own schema and semantics; mixing OCP profiles and schemas into it invites incompatible implementations.
- **Target version:** 0.4
- **Target layer:** binding:http discovery
- **Affected artifacts:** discovery schema; HTTP binding; OAuth mapping
- **Security impact:** Supports exact issuer/resource comparison without schema pollution.
- **Privacy impact:** Avoids exposing unnecessary OCP capability metadata through OAuth infrastructure.
- **Interoperability impact:** Preserves both standards' namespaces.
- **Validation requirement:** Discovery links resolve and mismatch/spoofing fixtures fail.
- **Status:** closed

### OCP-NR-048 — Accepted

- **Sources:** SEC:SECDELTA-002; R1:audience/forwarding; R2:audience/forwarding; R3:audience/forwarding; B0:audience; LEAD:independent determination
- **Conflict set:** CS-ID-001, CS-CRYPTO-001
- **Normalized recommendation:** Replace conflated audience arrays with exactly one delivery recipient and authenticated client-instance binding per runtime package, plus a separately approved set of every plaintext processing recipient.
- **Disposition:** Accepted
- **Rationale:** One encryption/alias set cannot securely represent independent recipients, model providers, subprocessors, and peer delivery clients.
- **Target version:** 0.4
- **Target layer:** core:request/receipt/package
- **Affected artifacts:** client declaration; request; receipt; package schemas; fixtures
- **Security impact:** Binds delivery to one instance and prevents peer reuse.
- **Privacy impact:** Makes all plaintext processors visible to the reviewer.
- **Interoperability impact:** Defines recipient roles unambiguously.
- **Validation requirement:** Undeclared processors, wrong instance, peer reuse, and processor changes reject; peer delivery creates a separate package and alias set.
- **Status:** implemented

### OCP-NR-049 — Accepted

- **Sources:** SEC:§4.2; B0:delegation none; SYN:§9.2
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Define subprocessing as declared plaintext processing without OCP retrieval/proposal/transfer/further-delegation rights; define delegation as authority for an independently acting child principal and keep it disabled in baseline.
- **Disposition:** Accepted
- **Rationale:** Conflating processing with delegation either hides disclosure or accidentally grants authority.
- **Target version:** 0.4
- **Target layer:** core terminology and profiles
- **Affected artifacts:** client declaration; request/receipt; delegation profile; privacy section
- **Security impact:** Prevents subprocessor authority escalation.
- **Privacy impact:** Requires processor disclosure.
- **Interoperability impact:** Standardizes role boundaries.
- **Validation requirement:** Fixtures show declared processors cannot call OCP operations and undeclared processing blocks issuance.
- **Status:** implemented

### OCP-NR-050 — Accepted

- **Sources:** SEC:SECDELTA-003,§4.3; B0:context_package schema; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Discriminate package entries by layer and disclosure, require content_schema_uri for structured JSON, validate accepted context as context_item, and bind evidence/artifact entries to supported profile schemas.
- **Disposition:** Accepted
- **Rationale:** Arbitrary JSON content and cross-layer disclosure values allow shape-valid semantic impersonation.
- **Target version:** 0.4
- **Target layer:** core:context_package
- **Affected artifacts:** context-package schema; profile schemas; positive/negative examples
- **Security impact:** Prevents arbitrary objects masquerading as accepted context.
- **Privacy impact:** Enforces independent layer permissions.
- **Interoperability impact:** Makes entry interpretation deterministic.
- **Validation requirement:** Empty content, schema mismatch, impossible layer/disclosure, unknown critical schema, and artifact-as-accepted fixtures fail.
- **Status:** implemented

### OCP-NR-051 — Accepted

- **Sources:** SEC:§4.3; B0:renderings; R1:prompt injection; R2:prompt injection; R3:prompt injection
- **Conflict set:** CS-IMPORT-001
- **Normalized recommendation:** Require every rendering to declare instruction_treatment untrusted_data, media type, digest, derivation references, and language when known; escape or sandbox active formats.
- **Disposition:** Accepted
- **Rationale:** Human-readable derivatives can carry the same injection and parser risks as raw entries.
- **Target version:** 0.4
- **Target layer:** core package rendering and import safety
- **Affected artifacts:** context-package schema; rendering fixtures; consumer guidance
- **Security impact:** Prevents rendering-to-control-channel escalation.
- **Privacy impact:** Reduces active-content leakage.
- **Interoperability impact:** Standardizes safe derivative metadata.
- **Validation requirement:** Markdown, HTML, SVG, links, filenames, and metadata remain inert with zero tool/network/action effects.
- **Status:** planned

### OCP-NR-052 — Accepted

- **Sources:** B0:context/action boundary; SYN:§3.3; ARCH:invariants; R1:general; R2:general; R3:general
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Preserve immutable invariant external_action_authority none: context, evidence, artifacts, accepted items, receipts, signatures, HIC signals, and continuity observations never authorize purchases, messages, publication, deployment, deletion, tools, or other external actions.
- **Disposition:** Accepted
- **Rationale:** Context visibility and action permission are separate trust domains.
- **Target version:** 0.4
- **Target layer:** core invariant
- **Affected artifacts:** common/package/profile schemas; security section; hostile fixtures
- **Security impact:** Blocks action-authority smuggling.
- **Privacy impact:** Prevents personal context from becoming implicit consent.
- **Interoperability impact:** Defines a universal negative invariant.
- **Validation requirement:** All object/profile schemas carry or inherit the invariant and hostile content causes zero external effects.
- **Status:** implemented

### OCP-NR-053 — Modified

- **Sources:** B0:import trust zones; SYN:§6.5,§9.3; SEC:§1; R2:quarantine; R3:quarantine
- **Conflict set:** CS-IMPORT-001
- **Normalized recommendation:** Keep raw, parsed, mapped, and accepted import trust zones; quarantine is a state boundary, not automatically a new portable object, and no parsed/mapped item may become accepted without proposal/review.
- **Disposition:** Modified
- **Rationale:** A universal quarantine wrapper can hide trust transitions; explicit zones preserve where transformations occurred.
- **Target version:** 0.4
- **Target layer:** import safety and adapter conformance
- **Affected artifacts:** import lifecycle; adapter fixtures; semantic tests
- **Security impact:** Prevents parser or mapping output from gaining trust.
- **Privacy impact:** Keeps imported dossiers out of accepted state.
- **Interoperability impact:** Standardizes import phases without forcing one storage object.
- **Validation requirement:** Raw-to-accepted and mapped-to-accepted shortcuts fail; each transformation is traceable and loss-reported.
- **Status:** planned

### OCP-NR-054 — Rejected

- **Sources:** R2:strip markup/code; R3:strip markup/code; SEC:§2; B0:parser safety
- **Conflict set:** CS-IMPORT-001
- **Normalized recommendation:** Sanitize imports by destructively stripping markup, code blocks, instruction-looking text, or signed bytes before further use.
- **Disposition:** Rejected
- **Rationale:** Phrase stripping is bypassable, breaks evidence/digests/round trips, and creates false confidence.
- **Target version:** 0.4
- **Target layer:** import safety
- **Affected artifacts:** parser rules; artifact/source schemas; fixtures
- **Security impact:** Avoids sanitizer-based trust escalation.
- **Privacy impact:** Preserves evidence while limiting exposure.
- **Interoperability impact:** Maintains byte and derivation integrity.
- **Validation requirement:** Fixtures preserve raw digests, identify derivatives, and show both remain inert.
- **Status:** closed

### OCP-NR-055 — Accepted

- **Sources:** SEC:SECDELTA-006,§4.6; B0:source trust enum; V09:authority
- **Conflict set:** CS-PROV-001, CS-CRYPTO-001
- **Normalized recommendation:** Replace unsupported provider_signed and credential_verified labels with signature_verified and credential_proof_verified states that conditionally require exact verification evidence.
- **Disposition:** Accepted
- **Rationale:** A label without verifier, covered digest, issuer, method, status time, result, and limitations is an assurance overclaim.
- **Target version:** 0.4
- **Target layer:** core:source_record
- **Affected artifacts:** source-record schema; verification-evidence schema; fixtures
- **Security impact:** Binds verification claims to evidence.
- **Privacy impact:** Prevents verified from being shown as true/authorized.
- **Interoperability impact:** Makes assurance states reproducible.
- **Validation requirement:** Verified states without complete evidence reject; valid proof never changes acceptance, sensitivity, instruction treatment, or authority.
- **Status:** planned

### OCP-NR-056 — Accepted

- **Sources:** SEC:SECDELTA-007,§4.4; B0:digest rules; V09:canonicalization; LEAD:independent determination
- **Conflict set:** CS-CRYPTO-001
- **Normalized recommendation:** Specify UTF-8 without BOM, reject invalid UTF-8, lone surrogates, duplicate names, non-finite/unsupported values, and use RFC 8785 JCS for digested JSON with an exact omitted-member rule.
- **Disposition:** Accepted
- **Rationale:** Hand-sorted JSON and optional canonicalization metadata do not provide cross-language digest equivalence.
- **Target version:** 0.4
- **Target layer:** core serialization
- **Affected artifacts:** serialization section; common schema; reference validator; JCS fixtures
- **Security impact:** Prevents ambiguous digest/signature inputs.
- **Privacy impact:** Avoids divergent redaction/selection over duplicate keys.
- **Interoperability impact:** Defines identical canonical bytes.
- **Validation requirement:** Official and OCP JCS vectors pass in at least two independent language stacks; forbidden inputs reject before schema/digest processing.
- **Status:** planned

### OCP-NR-057 — Accepted

- **Sources:** SEC:SECDELTA-007; B0:value numbers; SYN:Appendix A
- **Conflict set:** None
- **Normalized recommendation:** Constrain JSON number handling to JCS/IEEE-754-compatible values and require canonical string/profile representations for precision-sensitive decimals or integers that cannot round-trip safely.
- **Disposition:** Accepted
- **Rationale:** Unbounded JSON numbers produce silent cross-language value and digest changes.
- **Target version:** 0.4
- **Target layer:** core serialization/value model
- **Affected artifacts:** common schema; value profiles; JCS fixtures
- **Security impact:** Prevents value substitution through numeric ambiguity.
- **Privacy impact:** No material direct effect.
- **Interoperability impact:** Preserves exact quantities across languages.
- **Validation requirement:** Boundary, exponent, negative-zero, 2^53, and high-precision decimal vectors have deterministic outcomes.
- **Status:** implemented

### OCP-NR-058 — Accepted

- **Sources:** SEC:SECDELTA-008,§4.7; B0:proposal_rights; R1:propose_only; R2:propose_only
- **Conflict set:** None
- **Normalized recommendation:** Replace binary proposal_rights with bounded operation, target/create selectors, spaces, predicates/kinds, maximum sensitivity, source/evidence attachment rights, time, client-instance, and local-policy intersection.
- **Disposition:** Accepted
- **Rationale:** propose_only currently leaves create, revise, target, attachment scope, and any future profile-gated withdrawal semantics ambiguous.
- **Target version:** 0.4
- **Target layer:** core:request/receipt/package/proposal
- **Affected artifacts:** proposal rights schema; proposal validator; fixtures
- **Security impact:** Attenuates write-proposal capability.
- **Privacy impact:** Blocks unrelated sensitive/third-party attachments.
- **Interoperability impact:** Makes proposal authorization testable.
- **Validation requirement:** Cross-space, unapproved create/revise, unsupported baseline withdrawal, excessive sensitivity, and unrelated source-reference fixtures reject.
- **Status:** implemented

### OCP-NR-059 — Deferred

- **Sources:** R1:auto low-risk acceptance; R2:auto low-risk acceptance; B0:auto-review deferred; ARCH:reviewer decisions; SEC:§4.7
- **Conflict set:** CS-ACCEPT-001
- **Normalized recommendation:** Do not permit automatic low-risk acceptance in core; defer any Auto-Review Profile until strict exclusions, reversible audit, rate/bulk controls, trusted policy ownership, and human testing exist.
- **Disposition:** Deferred
- **Rationale:** Risk labels are context-dependent and automation undermines the no-silent-write invariant.
- **Target version:** future profile
- **Target layer:** profile:auto-review
- **Affected artifacts:** review lifecycle; roadmap; conformance
- **Security impact:** Prevents automated accepted-state poisoning.
- **Privacy impact:** Prevents silent accumulation of sensitive context.
- **Interoperability impact:** Keeps core review semantics unambiguous.
- **Validation requirement:** No core transition accepts by silence, timeout, model score, or client policy; future profile requires adversarial and human review.
- **Status:** deferred

### OCP-NR-060 — Accepted

- **Sources:** SEC:SECDELTA-010; B0:declaration renewal; R1:client declaration; R2:client declaration
- **Conflict set:** None
- **Normalized recommendation:** Bind the exact client-declaration snapshot into request and receipt; require active/unexpired status at issuance/use and suspend approval after material processor, model-provider, retention, training, or deletion-capability change.
- **Disposition:** Accepted
- **Rationale:** Consent to one declaration revision must not silently cover materially different behavior.
- **Target version:** 0.4
- **Target layer:** core decision chain
- **Affected artifacts:** declaration/request/receipt schemas; lifecycle; fixtures
- **Security impact:** Prevents client substitution and declaration drift.
- **Privacy impact:** Requires visible re-review of material data-use changes.
- **Interoperability impact:** Defines renewal triggers.
- **Validation requirement:** Expired, revoked, revised, or materially changed declaration cases suspend receipt/package with no disclosure.
- **Status:** implemented

### OCP-NR-061 — Accepted

- **Sources:** SEC:SECDELTA-011,§4.8; B0:pairwise aliases; ARCH:§5.5
- **Conflict set:** CS-ID-001
- **Normalized recommendation:** Require package-local aliases with at least 128 bits of CSPRNG unpredictability or stable pairwise aliases from random mapping or a provider-secret domain-separated PRF including verified audience, instance, version/epoch, and appropriate scope/purpose.
- **Disposition:** Accepted
- **Rationale:** An unkeyed hash or predictable identifier enables enumeration and correlation.
- **Target version:** 0.4
- **Target layer:** core identifiers
- **Affected artifacts:** identifier rules; package/transfer schemas; alias fixtures
- **Security impact:** Prevents alias guessing and ID recovery.
- **Privacy impact:** Reduces cross-recipient correlation.
- **Interoperability impact:** Defines equivalent safe construction requirements.
- **Validation requirement:** Multi-audience/instance/epoch tests show no reuse, raw-ID substring, reversible encoding, UUIDv1, counter, or public-hash construction.
- **Status:** planned

### OCP-NR-062 — Rejected

- **Sources:** R1:mandatory signature/JWE/age; R2:AES-GCM public-key rule; R3:AES-GCM public-key rule; B0:unavailable classes; ARCH:§3.4; SEC:§2,§4.5
- **Conflict set:** CS-CRYPTO-001
- **Normalized recommendation:** Mandate signatures and named JWS/JWE/age or AES-256-GCM rules in core without a complete registered construction and vectors.
- **Disposition:** Rejected
- **Rationale:** Naming primitives without a full construction is unsafe; AES-GCM is symmetric and DPoP does not encrypt packages.
- **Target version:** security profile 0.1-draft
- **Target layer:** security profiles
- **Affected artifacts:** remote/offline security profile; availability registry; crypto fixtures
- **Security impact:** Avoids custom or incomplete cryptographic constructions.
- **Privacy impact:** Prevents false confidentiality assurance.
- **Interoperability impact:** Requires exact suites and vectors.
- **Validation requirement:** SEC-001/002 and XFR-004 remain unavailable until selected profiles pass independent positive/negative vectors.
- **Status:** closed

### OCP-NR-063 — Accepted

- **Sources:** SEC:SECDELTA-004,§4.5; B0:offline manifest; ARCH:security profile; LEAD:independent determination
- **Conflict set:** CS-CRYPTO-001, CS-PACKAGE-001
- **Normalized recommendation:** Redesign offline protection without signature self-reference: manifest covers ciphertext payload entries; canonical signed view excludes detached signature object; security members are separately declared; physical members equal manifest plus payload plus security sets.
- **Disposition:** Accepted
- **Rationale:** A signature cannot cover a manifest containing the digest of that same signature without an explicit excluded view.
- **Target version:** offline security profile 0.1-draft
- **Target layer:** binding:offline and security profile
- **Affected artifacts:** offline manifest schema; archive validator; crypto vectors
- **Security impact:** Creates an unambiguous signed/encrypted view.
- **Privacy impact:** Supports recipient confidentiality when implemented.
- **Interoperability impact:** Defines exact construction order and members.
- **Validation requirement:** Self-reference, missing member, wrong recipient/instance, altered manifest/ciphertext, untrusted key, alg:none, and downgrade fixtures fail before plaintext release.
- **Status:** implemented

### OCP-NR-064 — Rejected

- **Sources:** R1:DPoP non-forwarding; R2:DPoP non-forwarding; R3:DPoP non-forwarding; SEC:§2; ARCH:§5.4
- **Conflict set:** CS-CRYPTO-001, CS-AUTH-001
- **Normalized recommendation:** Require DPoP for every client and treat it as cryptographic non-forwarding protection for delivered plaintext.
- **Disposition:** Rejected
- **Rationale:** DPoP constrains token use, not an authorized client's handling of plaintext.
- **Target version:** 0.4
- **Target layer:** security and OAuth binding
- **Affected artifacts:** security section; OAuth/RAR profile; client-declaration semantics
- **Security impact:** Prevents false non-forwarding assurance.
- **Privacy impact:** Makes downstream plaintext exposure explicit.
- **Interoperability impact:** Allows mTLS, OS-bound, local-key, and other profiles.
- **Validation requirement:** Documentation and fixtures separate token sender constraint from package confidentiality and recipient behavior.
- **Status:** closed

### OCP-NR-065 — Accepted

- **Sources:** SEC:SECDELTA-012; B0:archive safety; INV:ZIP analysis
- **Conflict set:** CS-PACKAGE-001
- **Normalized recommendation:** Require exact normalized physical archive-member equality with the manifest and reject hidden/unlisted members, path collisions, local/central header disagreement, symlinks/hardlinks, unsafe paths, trailing ambiguity, excessive nesting, and bombs.
- **Disposition:** Accepted
- **Rationale:** Manifest validation alone cannot detect parser differentials or undeclared payloads.
- **Target version:** 0.4
- **Target layer:** binding:offline/import safety
- **Affected artifacts:** offline binding; archive validator; hostile corpus
- **Security impact:** Blocks archive smuggling and traversal.
- **Privacy impact:** Prevents hidden content import/disclosure.
- **Interoperability impact:** Defines deterministic archive acceptance.
- **Validation requirement:** IMP-005 class corpus remains quarantined or rejected with no writes outside quarantine and no ambient network/credential access.
- **Status:** planned

### OCP-NR-066 — Accepted

- **Sources:** SEC:SECDELTA-015; B0:secret prohibition; BRIEF:Security Review
- **Conflict set:** None
- **Normalized recommendation:** Add an end-to-end synthetic-secret containment requirement covering sources, proposals, packages, renderings, errors, events, logs, analytics, embeddings, and model input.
- **Disposition:** Accepted
- **Rationale:** A prose-only secret ban does not demonstrate exclusion across all egress surfaces.
- **Target version:** 0.4
- **Target layer:** security conformance
- **Affected artifacts:** assertion registry; semantic/hostile fixtures; logging guidance
- **Security impact:** Reduces credential/key exfiltration.
- **Privacy impact:** Protects high-risk authentication data.
- **Interoperability impact:** Defines observable containment behavior.
- **Validation requirement:** Synthetic keys, cookies, passwords, private keys, and recovery codes yield zero prohibited disclosures across every carrier.
- **Status:** planned

### OCP-NR-067 — Accepted

- **Sources:** SEC:SECDELTA-014,§4.9; B0:event guidance; V09:telemetry
- **Conflict set:** CS-EVENT-001
- **Normalized recommendation:** Prohibit raw entry/content digests, stable aliases, free-text purposes/HIC signals, filenames, relationship IDs, or cross-purpose correlators in general telemetry; use opaque event-local refs or purpose-scoped keyed commitments when justified.
- **Disposition:** Accepted
- **Rationale:** Unkeyed low-entropy digests are dictionary or equality oracles even when content is absent.
- **Target version:** 0.4
- **Target layer:** event/telemetry binding
- **Affected artifacts:** event registry; telemetry guidance; fixtures
- **Security impact:** Limits telemetry correlation and guessing.
- **Privacy impact:** Minimizes personal-data exhaust.
- **Interoperability impact:** Defines safe reference-first event data.
- **Validation requirement:** Low-entropy and stable artifact digest attempts are rejected from general telemetry or replaced by approved scoped references.
- **Status:** planned

### OCP-NR-068 — Accepted

- **Sources:** SEC:SECDELTA-016; B0:time rules; V09:freshness
- **Conflict set:** None
- **Normalized recommendation:** Define comparison instants, allowed clock skew per binding, future-issued limits, complete cross-field temporal order, stale declaration/evidence handling, and timezone-independent comparison; wall-clock time never resolves write conflicts.
- **Disposition:** Accepted
- **Rationale:** Partial timestamp rules create inconsistent expiry and replay behavior.
- **Target version:** 0.4
- **Target layer:** core time semantics and bindings
- **Affected artifacts:** common schema; binding registries; TIME fixtures
- **Security impact:** Constrains replay/future-dating.
- **Privacy impact:** Stops use of stale approval or evidence.
- **Interoperability impact:** Gives deterministic time evaluation.
- **Validation requirement:** Boundary/skew/future/expired/order/timezone cases produce registered deterministic errors.
- **Status:** implemented

### OCP-NR-069 — Accepted

- **Sources:** R1:third-party; R2:third-party; R3:third-party; B0:personal core exclusions; SYN:§9.2; SEC:SECDELTA-017
- **Conflict set:** None
- **Normalized recommendation:** Default Core Personal to exclude or quarantine raw third-party and organization-managed content; require relationship-only/coarsened representations or separate authority profiles for broader disclosure.
- **Disposition:** Accepted
- **Rationale:** Possession of another person's or employer's data does not create disclosure authority.
- **Target version:** 0.4
- **Target layer:** privacy and core conformance
- **Affected artifacts:** privacy section; import/package policy; fixtures
- **Security impact:** Reduces organizational exfiltration.
- **Privacy impact:** Protects non-subjects and joint data.
- **Interoperability impact:** Defines a conservative default.
- **Validation requirement:** Second-subject messages, contact/location/health metadata, mixed-source records, and organization provenance are omitted/quarantined with non-disclosing errors.
- **Status:** planned

### OCP-NR-070 — Accepted

- **Sources:** R1:revocation/deletion; R2:revocation/deletion; R3:revocation/deletion; B0:privacy semantics; SYN:§6.7; ARCH:invariant 9
- **Conflict set:** CS-ERASURE-001
- **Normalized recommendation:** Keep revocation, retention expiry, deletion request, deletion acknowledgment, provider-reported completion, cryptographic erasure, downstream copies, and independent verification as separate bounded claims.
- **Disposition:** Accepted
- **Rationale:** No protocol can recall plaintext or infer downstream deletion from revocation.
- **Target version:** 0.4
- **Target layer:** core privacy plus erasure profile
- **Affected artifacts:** privacy section; receipt lifecycle; erasure profile; UI language
- **Security impact:** Avoids treating deletion reports as authority.
- **Privacy impact:** Prevents deletion theater.
- **Interoperability impact:** Standardizes qualified state names.
- **Validation requirement:** UI/schema fixtures cannot express independent verification without verifier evidence, scope, exclusions, and limitations.
- **Status:** implemented

### OCP-NR-071 — Rejected

- **Sources:** R3:tombstone means purged; B0:tombstone semantics; SEC:§2
- **Conflict set:** CS-ERASURE-001
- **Normalized recommendation:** Define tombstoned to prove that underlying record data has been purged.
- **Disposition:** Rejected
- **Rationale:** A state flag cannot establish remote erasure.
- **Target version:** 0.4
- **Target layer:** privacy lifecycle
- **Affected artifacts:** lifecycle registry; erasure profile; examples
- **Security impact:** Prevents state-flag assurance escalation.
- **Privacy impact:** Keeps deletion limitations honest.
- **Interoperability impact:** Avoids divergent purge interpretations.
- **Validation requirement:** Tombstone examples include explicit exclusions and do not use verified-deleted language.
- **Status:** closed

### OCP-NR-072 — Rejected

- **Sources:** R1:package consumed/retained/destroyed; R2:package consumed/retained/destroyed; B0:provider-visible lifecycle; ARCH:reviewer decisions
- **Conflict set:** CS-ERASURE-001
- **Normalized recommendation:** Treat consumed, retained, or destroyed as authoritative provider-known package lifecycle states.
- **Disposition:** Rejected
- **Rationale:** A provider cannot know what an independent recipient did with plaintext merely from protocol state.
- **Target version:** 0.4
- **Target layer:** package lifecycle
- **Affected artifacts:** lifecycle registry; client declaration; assurance profile
- **Security impact:** Avoids trusting unverifiable recipient claims.
- **Privacy impact:** Prevents false retention/deletion UI.
- **Interoperability impact:** Keeps observable and asserted states distinct.
- **Validation requirement:** Lifecycle registry includes only provider-observable states; recipient claims carry evidence/assurance labels.
- **Status:** closed

### OCP-NR-073 — Deferred

- **Sources:** R3:SD-JWT/BBS+ core; SEC:§2; ARCH:credential placement
- **Conflict set:** CS-CRYPTO-001
- **Normalized recommendation:** Defer SD-JWT, BBS+, or other selective-disclosure systems from core until realistic graph, array, artifact, revocation, and linkability experiments justify a profile.
- **Disposition:** Deferred
- **Rationale:** Arbitrary OCP graphs and external artifacts do not map safely to one credential disclosure construction.
- **Target version:** future security/domain profile
- **Target layer:** profile:selective-disclosure
- **Affected artifacts:** credential profile; security roadmap; fixtures
- **Security impact:** Avoids premature cryptographic coupling.
- **Privacy impact:** Requires explicit linkability analysis.
- **Interoperability impact:** Leaves room for multiple proven systems.
- **Validation requirement:** Independent prototypes cover arrays/graphs/artifacts/status and measure correlation before profile selection.
- **Status:** deferred

### OCP-NR-074 — Accepted

- **Sources:** R1:signature/truth; R2:signature/truth; R3:signature/truth; B0:trust boundaries; SEC:§4.6; V09:provenance limits
- **Conflict set:** CS-PROV-001, CS-CRYPTO-001
- **Normalized recommendation:** State normatively that valid signature or credential proof establishes only the profile-defined covered bytes and control relationship; it never proves truth, safety, current authority, acceptance, sensitivity, or disclosure rights.
- **Disposition:** Accepted
- **Rationale:** Cryptographic validity is routinely overread as semantic trust.
- **Target version:** 0.4
- **Target layer:** security invariant
- **Affected artifacts:** source verification; credential profile; security section; fixtures
- **Security impact:** Prevents trust laundering.
- **Privacy impact:** Prevents proof from widening disclosure.
- **Interoperability impact:** Defines evidence semantics precisely.
- **Validation requirement:** Verified hostile/sensitive/imported fixtures remain untrusted and unaccepted absent independent decisions.
- **Status:** implemented

### OCP-NR-075 — Accepted

- **Sources:** R1:preserved artifact; R2:digest+copy; R3:digest+copy; B0:artifact custody; V09:availability
- **Conflict set:** CS-PROV-001
- **Normalized recommendation:** A preserved or managed-copy claim requires an independent readable copy, exact byte digest, size, verification time, custody mode, source-dependency/availability state, and evidence; a source URI or digest alone is insufficient.
- **Disposition:** Accepted
- **Rationale:** Provenance is not preservation and source URLs disappear.
- **Target version:** artifact profile 0.1-draft
- **Target layer:** profile:artifact-lineage
- **Affected artifacts:** artifact schema; custody vocabulary; fixtures
- **Security impact:** Detects byte mismatch and stale verification.
- **Privacy impact:** Keeps raw-copy custody visible.
- **Interoperability impact:** Makes preservation classes testable.
- **Validation requirement:** Missing copy, mismatched bytes, stale verification, lost source, and derivative-only cases produce bounded states.
- **Status:** implemented

### OCP-NR-076 — Accepted

- **Sources:** B0:parser controls; R1:prompt injection; R2:prompt injection; R3:prompt injection; SEC:IMP-006; V09:resolver isolation
- **Conflict set:** CS-IMPORT-001
- **Normalized recommendation:** Treat all context and imported carriers—including signed or subject-confirmed JSON keys/values, filenames, URLs, EXIF/OCR, audio transcripts, PDF, code, and nested archives—as untrusted data with zero privileged effects.
- **Disposition:** Accepted
- **Rationale:** Trust labels and human confirmation do not make content safe instructions or parser input.
- **Target version:** 0.4
- **Target layer:** import and consumer safety
- **Affected artifacts:** security section; hostile corpus; consumer conformance
- **Security impact:** Defends indirect prompt and parser attacks.
- **Privacy impact:** Prevents exfiltration through carrier metadata.
- **Interoperability impact:** Defines host-observable containment.
- **Validation requirement:** Hostile carrier corpus causes zero policy, tool, network, credential, accepted-state, secret, or external-action changes.
- **Status:** planned

### OCP-NR-077 — Modified

- **Sources:** V09:no hidden blocking; B0:host policy boundary; ARCH:invariant 1; V09:reconciliation
- **Conflict set:** CS-AUTH-001, CS-CONT-001
- **Normalized recommendation:** OCP observes and presents but does not secretly block or authorize external actions; hosts own and attribute any external policy decision, while OCP may create its own authorized records and audit evidence.
- **Disposition:** Modified
- **Rationale:** Observe-only must not imply OCP cannot create protocol records, and no-hidden-blocking must not prevent hosts from enforcing their own policy.
- **Target version:** 0.4
- **Target layer:** architecture invariant
- **Affected artifacts:** non-goals; host integration guidance; profiles
- **Security impact:** Keeps enforcement ownership explicit.
- **Privacy impact:** Prevents covert human-state-based blocking.
- **Interoperability impact:** Clarifies OCP/host division of responsibility.
- **Validation requirement:** Examples attribute external decisions to host authority and OCP outputs remain non-executable data.
- **Status:** implemented

### OCP-NR-078 — Accepted

- **Sources:** R1:HTTP binding; R2:HTTP binding; B0:HTTP profile; ARCH:§3.4; SYN:§10.2
- **Conflict set:** None
- **Normalized recommendation:** Publish a remote HTTP binding with resource URIs, methods, provisional media types, idempotency, ETags, pagination where applicable, exact errors, discovery, and authorization hooks; do not imply IANA registration.
- **Disposition:** Accepted
- **Rationale:** The semantic model is not independently implementable as a remote protocol without deterministic transport behavior.
- **Target version:** binding 0.1-draft
- **Target layer:** binding:http
- **Affected artifacts:** HTTP binding; OpenAPI; problem schema; fixtures
- **Security impact:** Defines authenticated operations and concurrency.
- **Privacy impact:** Defines non-disclosing errors and minimized responses.
- **Interoperability impact:** Enables compatible remote implementations.
- **Validation requirement:** OpenAPI/reference checks, method/status/error fixtures, idempotency and ETag tests pass; media types remain labeled provisional.
- **Status:** planned

### OCP-NR-079 — Accepted

- **Sources:** B0:local binding; ARCH:§3.4; SYN:§10.4; SEC:release gates
- **Conflict set:** CS-AUTH-001
- **Normalized recommendation:** Publish a local-broker binding using authenticated local IPC, OS identity/capabilities, explicit app-instance binding, and equivalent consent/containment; localhost or filesystem possession alone is never authority.
- **Disposition:** Accepted
- **Rationale:** Local-first is a core deployment goal but loopback transport is not a trust boundary.
- **Target version:** binding 0.1-draft
- **Target layer:** binding:local-broker
- **Affected artifacts:** local binding; security assertions; examples
- **Security impact:** Prevents local app impersonation.
- **Privacy impact:** Keeps on-device consent and recipient identity explicit.
- **Interoperability impact:** Supports storage-neutral local implementations.
- **Validation requirement:** Wrong process/user/app instance and file-copy cases fail without content release.
- **Status:** planned

### OCP-NR-080 — Modified

- **Sources:** R1:offline ZIP; R2:offline ZIP; B0:offline manifest; ARCH:§3.4; INV:ZIP analysis
- **Conflict set:** CS-PACKAGE-001, CS-CRYPTO-001
- **Normalized recommendation:** Keep offline archive as a binding with safe manifest/serialization semantics; structural offline conformance may ship while cryptographic protection remains unavailable until its security profile executes.
- **Disposition:** Modified
- **Rationale:** Archive portability and archive protection are separate maturity claims.
- **Target version:** binding 0.1-draft
- **Target layer:** binding:offline
- **Affected artifacts:** offline manifest; archive validator; availability registry
- **Security impact:** Avoids structural validation being mistaken for confidentiality/authenticity.
- **Privacy impact:** Supports local transfer with honest protection limits.
- **Interoperability impact:** Defines a common archive shape.
- **Validation requirement:** Structural archive tests pass and XFR-004 stays unavailable unless independent crypto vectors pass.
- **Status:** implemented

### OCP-NR-081 — Modified

- **Sources:** B0:transfer_manifest ambiguity; ARCH:§3.5; INV:pack inventory; SYN:§6.6
- **Conflict set:** CS-TRANSFER-001, CS-CORE-001
- **Normalized recommendation:** Keep loss-aware export invariants normative but move transfer_manifest schema/lifecycle to a Transfer Binding required for portable-provider/exporter/importer claims, not the nine-record semantic core.
- **Disposition:** Modified
- **Rationale:** Portability is central, but runtime-only clients need not implement durable transfer mechanics.
- **Target version:** binding 0.1-draft
- **Target layer:** binding:transfer
- **Affected artifacts:** transfer schema; directory layout; conformance classes; README inventory
- **Security impact:** Keeps transfer credentials/custody out of core.
- **Privacy impact:** Separates user-directed bulk movement from runtime disclosure.
- **Interoperability impact:** Defines who must implement transfer.
- **Validation requirement:** Core inventory is nine; transfer claim dependencies and A→B→A loss-aware fixtures are explicit.
- **Status:** implemented

### OCP-NR-082 — Rejected

- **Sources:** R1:CloudEvents; R2:CloudEvents; R3:CloudEvents; B0:event registry; ARCH:reviewer decisions; SEC:§2; V09:event binding
- **Conflict set:** CS-EVENT-001
- **Normalized recommendation:** Require a CloudEvents event for every transition and treat that stream as mandatory audit/state machinery.
- **Disposition:** Rejected
- **Rationale:** CloudEvents is a delivery envelope, not the authoritative state, storage format, or ordering source.
- **Target version:** event binding 0.1-draft
- **Target layer:** binding:events
- **Affected artifacts:** event registry; audit model; CloudEvents mapping
- **Security impact:** Prevents event arrival from authorizing state.
- **Privacy impact:** Minimizes event content.
- **Interoperability impact:** Composes without requiring one event bus.
- **Validation requirement:** Resource state remains authoritative; duplicate, delayed, missing, reordered, and redacted events do not change semantics.
- **Status:** closed

### OCP-NR-083 — Accepted

- **Sources:** R1:errors; R2:errors; B0:RFC9457; V09:§8.15; ARCH:§3.4
- **Conflict set:** None
- **Normalized recommendation:** Use RFC 9457 Problem Details with a governed, namespaced error registry specifying status, retryability, disclosure behavior, and profile-specific extension rules.
- **Disposition:** Accepted
- **Rationale:** Deterministic failures are required without leaking whether sensitive records exist.
- **Target version:** 0.4
- **Target layer:** binding:http and registries
- **Affected artifacts:** problem schema; error registry; OpenAPI; negative fixtures
- **Security impact:** Standardizes non-disclosing failures.
- **Privacy impact:** Reduces existence and policy leakage.
- **Interoperability impact:** Provides deterministic error handling.
- **Validation requirement:** Every negative fixture maps to a registered error and disclosure-safe response.
- **Status:** implemented

### OCP-NR-084 — Accepted

- **Sources:** R1:state machines; R2:state machines; B0:lifecycle registry; SYN:§6; V09:idempotency
- **Conflict set:** None
- **Normalized recommendation:** Keep explicit lifecycles, immutable revisions, optimistic concurrency, If-Match/ETags, and principal/endpoint/version/digest-bound idempotency; prohibit direct state jumping and wall-clock conflict resolution.
- **Disposition:** Accepted
- **Rationale:** State prose without executable transitions creates lost updates and replay ambiguity.
- **Target version:** 0.4
- **Target layer:** core lifecycles and bindings
- **Affected artifacts:** lifecycle registry; HTTP binding; semantic fixtures
- **Security impact:** Prevents replay and state substitution.
- **Privacy impact:** Prevents stale edits or resurrection.
- **Interoperability impact:** Defines deterministic transition behavior.
- **Validation requirement:** Every state/transition is registry-backed; illegal jumps, stale revisions, and idempotency reuse under changed inputs fail.
- **Status:** planned

### OCP-NR-085 — Accepted

- **Sources:** B0:partial package/transfer; V09:§8.15.5; ARCH:unknown semantics; SYN:§6.6
- **Conflict set:** None
- **Normalized recommendation:** Require partial packages/transfers to distinguish omitted, unavailable, redacted, unauthorized, corrupted, unsupported, and intentionally excluded entries without leaking sensitive existence.
- **Disposition:** Accepted
- **Rationale:** A generic missing state prevents round-trip accountability and deterministic recovery.
- **Target version:** 0.4
- **Target layer:** core package and transfer binding
- **Affected artifacts:** omission registry; package/transfer schemas; fixtures
- **Security impact:** Prevents fail-open use of missing data.
- **Privacy impact:** Supports coarsened non-disclosing omissions.
- **Interoperability impact:** Enables exact loss reports and retry behavior.
- **Validation requirement:** Each absence reason has a governed code, disclosure rule, retryability, and fixture.
- **Status:** planned

### OCP-NR-086 — Accepted

- **Sources:** R1:extensions; R2:extensions; B0:extension rules; ARCH:invariant 10; V09:extensions
- **Conflict set:** None
- **Normalized recommendation:** Preserve or loss-report unknown non-critical extension data while keeping it inert and unrendered; reject unknown critical semantics; distinguish semantic JSON preservation from exact opaque-byte preservation.
- **Disposition:** Accepted
- **Rationale:** Fail-open extension use is unsafe, while silently dropping unknown data breaks portability.
- **Target version:** 0.4
- **Target layer:** core extensibility and transfer
- **Affected artifacts:** common schema; extension registry; round-trip fixtures
- **Security impact:** Critical unknowns fail closed.
- **Privacy impact:** Unknown data is not silently exposed.
- **Interoperability impact:** Supports forward-compatible loss-aware round trips.
- **Validation requirement:** Unknown non-critical JSON survives or appears in loss report; unknown critical and altered signed opaque data reject.
- **Status:** planned

### OCP-NR-087 — Accepted

- **Sources:** R2:PAM overlap; B0:PAM analysis; ARCH:§3.4,release gate 3; SYN:§10.5; V09:mappings
- **Conflict set:** None
- **Normalized recommendation:** Make a field-level, lifecycle-level, cardinality-, proof-, and loss-aware mapping to exact PAM v1.0 the highest-priority adjacent-standard mapping; do not describe PAM as merely early research.
- **Disposition:** Accepted
- **Rationale:** PAM is the closest current overlap and differentiation depends on an exact boundary, not a narrative comparison.
- **Target version:** mapping 0.1-draft
- **Target layer:** mapping:PAM
- **Affected artifacts:** PAM mapping; fixtures; standards matrix
- **Security impact:** Keeps imported memory inert and provenance-labeled.
- **Privacy impact:** Maps memory disclosure without granting dossier authority.
- **Interoperability impact:** Defines concrete reuse versus OCP-added governance.
- **Validation requirement:** Pin PAM version/source and provide both-direction positive, lossy, unknown, and negative mappings.
- **Status:** implemented

### OCP-NR-088 — Modified

- **Sources:** R1:full PROV required; R2:PROV mapping; B0:provenance; ARCH:reviewer decisions; V09:§8.12.5
- **Conflict set:** CS-PROV-001
- **Normalized recommendation:** Use a minimal required OCP provenance model and publish an exact W3C PROV mapping; do not require full PROV Agent/Entity/Activity graphs on every core object.
- **Disposition:** Modified
- **Rationale:** Full PROV graph complexity burdens core and still does not prove truth, rights, acceptance, or preservation.
- **Target version:** 0.4 plus mapping
- **Target layer:** core provenance and mapping:PROV
- **Affected artifacts:** common/source schemas; PROV mapping; fixtures
- **Security impact:** Preserves derivation without trust overclaim.
- **Privacy impact:** Avoids unnecessary actor graph disclosure.
- **Interoperability impact:** Provides a bounded mapping to a mature standard.
- **Validation requirement:** Required provenance fields are schema-enforced and PROV round-trip loss is explicit.
- **Status:** planned

### OCP-NR-089 — Accepted

- **Sources:** R1:MCP/A2A; R2:MCP/A2A; B0:standards mappings; ARCH:§3.4; V09:§8.12.3-4
- **Conflict set:** CS-AUTH-001, CS-CORE-001
- **Normalized recommendation:** Treat MCP and A2A as optional carriage/capability mappings only; OCP must not define agent identity, task execution, tool runtime, or action delegation, and recipients revalidate OCP independently.
- **Disposition:** Accepted
- **Rationale:** MCP/A2A solve live tool/task communication, not governed accepted-context authority.
- **Target version:** mappings 0.1-draft
- **Target layer:** mapping:MCP/A2A
- **Affected artifacts:** mapping docs; agent examples; security assertions
- **Security impact:** Prevents metadata hints from becoming enforcement.
- **Privacy impact:** Requires new audience packages for handoff.
- **Interoperability impact:** Composes rather than competes.
- **Validation requirement:** Handoff fixtures use new audience aliases, no credentials, and separate action authorization.
- **Status:** planned

### OCP-NR-090 — Accepted

- **Sources:** R1:C2PA/VC/Solid; R2:C2PA/VC/Solid; B0:mappings; ARCH:§3.4; SYN:§10.5
- **Conflict set:** CS-PROV-001
- **Normalized recommendation:** Publish bounded mappings for C2PA, VC/SD-JWT, and Solid: C2PA proves defined media provenance, credentials prove defined statements/control, and Solid provides storage/access; none supplies accepted context, disclosure authority, truth, or preservation by itself.
- **Disposition:** Accepted
- **Rationale:** Adjacent standards should be reused without importing their claims beyond scope.
- **Target version:** mappings 0.1-draft
- **Target layer:** mappings
- **Affected artifacts:** C2PA mapping; VC mapping; Solid mapping; artifact/credential profiles
- **Security impact:** Keeps proof boundaries explicit.
- **Privacy impact:** Avoids identity/storage coupling.
- **Interoperability impact:** Reuses established ecosystems.
- **Validation requirement:** Each mapping pins source version, field cardinality, authority boundary, unknown behavior, and loss fixtures.
- **Status:** planned

### OCP-NR-091 — Modified

- **Sources:** R1:DPV/legal alignment; R2:DPV/legal alignment; B0:legal posture; V09:DPV; BRIEF:standards quality
- **Conflict set:** None
- **Normalized recommendation:** Use DPV and legal/regulatory sources only as optional pinned mappings/informative alignment; do not encode legal conclusions or claim GDPR, Data Act, AI Act, COPPA, or other compliance.
- **Disposition:** Modified
- **Rationale:** Vocabulary reuse is useful, but technical conformance cannot establish jurisdiction-specific compliance.
- **Target version:** 0.4 and mapping
- **Target layer:** mapping:privacy and legal considerations
- **Affected artifacts:** DPV mapping; privacy section; status notice
- **Security impact:** No direct effect.
- **Privacy impact:** Avoids compliance theater while retaining purpose/recipient vocabulary.
- **Interoperability impact:** Pins optional vocabulary terms.
- **Validation requirement:** Every legal claim is sourced, qualified, date-verified, and labeled informative; no conformance class claims legal compliance.
- **Status:** planned

### OCP-NR-092 — Partially Accepted

- **Sources:** V09:observation concepts; ARCH:§3.3; V09:reconciliation — §4-§10; LEAD:independent determination
- **Conflict set:** CS-CONT-001, CS-CORE-001
- **Normalized recommendation:** If release scope permits executable artifacts, publish Continuity Observation Profile 0.1-draft for immutable, exact-target observations/evaluations with four-valued results, profile/method/version, basis refs, freshness, evaluator, append-only change/restoration links, and no action authority.
- **Disposition:** Partially Accepted
- **Rationale:** Observation-before-interpretation, freshness, and restoration history are valuable, but they do not justify a second core or universal continuity truth state.
- **Target version:** profile 0.1-draft
- **Target layer:** profile:continuity-observation
- **Affected artifacts:** profile spec/schema; examples; assertions; availability
- **Security impact:** Pins evaluation inputs and prevents authority inheritance.
- **Privacy impact:** Keeps observation scope/purpose/time bounded.
- **Interoperability impact:** Creates a testable optional profile.
- **Validation requirement:** Strict schemas, deterministic fixtures, exact inputs/clock/resolver results, privacy review, and explicit availability are required; otherwise keep roadmap-only.
- **Status:** implemented

### OCP-NR-093 — Deferred

- **Sources:** V09:aggregate/admissibility; V09:reconciliation — §4,§8; ARCH:§3.3
- **Conflict set:** CS-CONT-001, CS-AUTH-001
- **Normalized recommendation:** Reject universal admissibility and intact/strained/degraded/broken aggregate states in core; allow only profile-specific non-authoritative evaluation results after independent deterministic evidence.
- **Disposition:** Deferred
- **Rationale:** Universal scores collapse heterogeneous conditions and are easily mistaken for permission, safety, or human capacity.
- **Target version:** future experimental profile
- **Target layer:** profile:continuity-evaluation
- **Affected artifacts:** roadmap; profile registry; research fixtures
- **Security impact:** Prevents score-to-authorization shortcuts.
- **Privacy impact:** Avoids global person/system status labels.
- **Interoperability impact:** Defers underdefined aggregation semantics.
- **Validation requirement:** Independent evaluators must agree on fixed inputs and profile-specific transitions before any registry proposal.
- **Status:** deferred

### OCP-NR-094 — Partially Accepted

- **Sources:** V09:HIC Runtime; V09:reconciliation — §4,§8; ARCH:§3.3; SEC:HIC privacy
- **Conflict set:** CS-HIC-001, CS-CORE-001
- **Normalized recommendation:** If executable and reviewed, publish Human Interaction Boundary Profile 0.1-draft limited to explicit pause, checkpoint, clarification request, slower pacing, and resume controls with expiry, inspect/correct/delete, local-first retention, and no raw free text by default.
- **Disposition:** Partially Accepted
- **Rationale:** Explicit human controls can preserve continuity without standardizing inferred mental or emotional states.
- **Target version:** profile 0.1-draft
- **Target layer:** profile:human-interaction-boundary
- **Affected artifacts:** profile spec/schema; privacy section; fixtures; availability
- **Security impact:** Signals remain data and cannot authorize/block.
- **Privacy impact:** Minimizes sensitive behavioral data.
- **Interoperability impact:** Defines a narrow explicit-control vocabulary.
- **Validation requirement:** Strict schemas, human/privacy/accessibility review, expiry/correction/deletion fixtures, and no-action tests are required; otherwise roadmap-only.
- **Status:** planned

### OCP-NR-095 — Rejected

- **Sources:** V09:fear/overload/hesitation/biometrics; V09:reconciliation — §4,§8; SEC:§1
- **Conflict set:** CS-HIC-001
- **Normalized recommendation:** Standardize inferred fear, overload, hesitation, uncertainty, covert sentiment, biometric, keystroke, silence-based, or demographic-proxy states as portable HIC data.
- **Disposition:** Rejected
- **Rationale:** These classes are error-prone, coercive, privacy-invasive, and easily misused for capacity or permission decisions.
- **Target version:** not in 0.4/profile 0.1
- **Target layer:** profile:HIC exclusions
- **Affected artifacts:** HIC profile; privacy/security sections; fixtures
- **Security impact:** Prevents inferred state from controlling outcomes.
- **Privacy impact:** Prohibits covert sensitive profiling.
- **Interoperability impact:** Avoids unstable behavioral ontologies.
- **Validation requirement:** Profile schemas and tests accept only explicit user controls/declarations and reject inferred sensitive classes.
- **Status:** closed

### OCP-NR-096 — Deferred

- **Sources:** V09:fork/merge; B0:optimistic concurrency; ARCH:§3.1; SYN:§5.2
- **Conflict set:** CS-CONT-001
- **Normalized recommendation:** Defer fork/merge, live sync, and multi-writer conflict protocols; retain immutable revisions, optimistic concurrency, and visible conflicts in core.
- **Disposition:** Deferred
- **Rationale:** General merge semantics depend on domain-specific authority and conflict rules and require implementation experiments.
- **Target version:** future profile
- **Target layer:** profile:live-sync/multi-writer
- **Affected artifacts:** roadmap; profile registry; experiments
- **Security impact:** Avoids unsafe last-write-wins or implicit authority.
- **Privacy impact:** Prevents merging contexts across scopes without review.
- **Interoperability impact:** Defers distributed-systems complexity.
- **Validation requirement:** At least two offline/multi-writer prototypes with conflict/authority fixtures before standardization.
- **Status:** deferred

### OCP-NR-097 — Accepted

- **Sources:** V09:resolver; B0:reference retrieval; SEC:resolver guidance; ARCH:profiles
- **Conflict set:** None
- **Normalized recommendation:** Require isolated resolvers with scheme/host allowlists, redirect and DNS rechecks, no ambient credentials, network/byte/time/depth bounds, sandboxing, audit minimization, and indeterminate failure rather than permissive fallback.
- **Disposition:** Accepted
- **Rationale:** External references create SSRF, credential leakage, parser, and availability hazards.
- **Target version:** 0.4/profile 0.1
- **Target layer:** binding:reference-retrieval/import safety
- **Affected artifacts:** resolver rules; error registry; hostile fixtures
- **Security impact:** Mitigates SSRF and resource exhaustion.
- **Privacy impact:** Prevents credential and internal-network disclosure.
- **Interoperability impact:** Defines deterministic bounded failure.
- **Validation requirement:** Redirect/DNS rebinding, metadata IP, ambient auth, oversized/slow content, and parser cases fail closed or indeterminate.
- **Status:** planned

### OCP-NR-098 — Accepted

- **Sources:** SEC:SECDELTA-005,§4.10; P0:assertions/report; BRIEF:Conformance; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Publish one assertion-results entry for every registered assertion with exactly one status: executed_pass, executed_fail, partial_evidence, not_executed, manual_required, unavailable, or not_applicable, plus scoped evidence. executed_pass requires a named system under test and complete evidence for every required facet; reference vectors alone use partial_evidence.
- **Disposition:** Accepted
- **Rationale:** The earlier baseline semantic report covered only 13 of 54 assertion IDs, and aggregate pass counts can be overread; the 0.4 register therefore distinguishes partial reference evidence from executed implementation passes.
- **Target version:** 0.4
- **Target layer:** conformance
- **Affected artifacts:** assertions.json; assertion-results.json; validation reports
- **Security impact:** Prevents unexecuted security claims from appearing passed.
- **Privacy impact:** Makes manual/privacy evidence gaps explicit.
- **Interoperability impact:** Provides complete machine-readable claim accounting.
- **Validation requirement:** Completeness validation fails missing or duplicate statuses, partial_evidence entries without scoped reference evidence, any executed_pass without a non-null named system_under_test or complete required facets, or aggregates that include anything except executed_pass.
- **Status:** implemented

### OCP-NR-099 — Accepted

- **Sources:** B0:54 assertions; P0:54 assertions; SEC:§5; BRIEF:Test Fixtures; ARCH:release gates
- **Conflict set:** None
- **Normalized recommendation:** Retain existing valid assertions and fixtures, add exact-reference, recipient-role, typed-entry, JSON/JCS, crypto-envelope, verification-evidence, proposal, secret, third-party, telemetry, time, archive, and result-accounting cases, and never reduce current negative coverage.
- **Disposition:** Accepted
- **Rationale:** The next wire version introduces new failure surfaces and must preserve proven 0.2 boundaries.
- **Target version:** 0.4
- **Target layer:** conformance
- **Affected artifacts:** assertion registry; semantic fixtures; positive/negative examples; validators
- **Security impact:** Expands adversarial coverage.
- **Privacy impact:** Adds recipient, secret, and third-party checks.
- **Interoperability impact:** Covers cross-object semantics beyond schema shape.
- **Validation requirement:** Every new normative MUST maps to an assertion or documented manual/unavailable status; coverage cannot regress from 0.2.
- **Status:** implemented

### OCP-NR-100 — Accepted

- **Sources:** SEC:JCS-001; BRIEF:Independent Implementation Review; ARCH:release gates; LEAD:independent determination
- **Conflict set:** CS-CRYPTO-001
- **Normalized recommendation:** Use conformant canonicalization and at least two independent language/validator lanes for strict JSON/JCS vectors and critical cross-record checks.
- **Disposition:** Accepted
- **Rationale:** One JavaScript validator and hand-written sorted serialization are insufficient evidence of cross-language determinism.
- **Target version:** 0.4
- **Target layer:** conformance tools
- **Affected artifacts:** reference validators; JCS fixtures; validation report
- **Security impact:** Detects canonicalization and parser differentials.
- **Privacy impact:** Detects divergent selection/redaction parsing.
- **Interoperability impact:** Provides cross-language evidence.
- **Validation requirement:** Independent stacks produce identical bytes/digests/results for allowed cases and consistent rejection for forbidden inputs.
- **Status:** planned

### OCP-NR-101 — Accepted

- **Sources:** B0:unavailable classes; ARCH:§3.4; SEC:release gates; P0:availability
- **Conflict set:** CS-CRYPTO-001, CS-HIC-001, CS-CONT-001
- **Normalized recommendation:** Keep Remote Security, offline protection, HIC conformance, and any universal continuity aggregate explicitly unavailable until their exact profiles, implementations, vectors, reviews, and evidence exist.
- **Disposition:** Accepted
- **Rationale:** Structural schemas or prose objectives do not prove deployed cryptography, human safety, or deterministic aggregation.
- **Target version:** 0.4
- **Target layer:** conformance availability
- **Affected artifacts:** availability registry; assertion results; status notice
- **Security impact:** Prevents false crypto claims.
- **Privacy impact:** Prevents false human-state/privacy claims.
- **Interoperability impact:** Scopes conformance honestly.
- **Validation requirement:** Unavailable claims cannot appear in aggregate passes or unqualified conformance statements.
- **Status:** implemented

### OCP-NR-102 — Accepted

- **Sources:** SEC:release gates; BRIEF:Security/Adversarial Review; B0:import safety caveat
- **Conflict set:** None
- **Normalized recommendation:** Treat schema/semantic harness results as local structural evidence only; Import Safety requires deployed sandbox/resource-boundary tests, and remote security requires profile implementations and adversarial review.
- **Disposition:** Accepted
- **Rationale:** JSON rejection cannot prove zero network, tool, parser escape, log leakage, or plaintext exposure in a real host.
- **Target version:** 0.4
- **Target layer:** conformance evidence
- **Affected artifacts:** validation report; conformance classes; security review
- **Security impact:** Separates code-path behavior from schema validity.
- **Privacy impact:** Prevents model/log leakage claims without observation.
- **Interoperability impact:** Clarifies evidence level for each class.
- **Validation requirement:** Reports label structural, semantic, deployed, independent, manual, and unavailable evidence separately.
- **Status:** implemented

### OCP-NR-103 — Accepted

- **Sources:** R1:three prototypes; R2:three prototypes; ARCH:pre-1.0 gates; SYN:§12.1; BRIEF:Independent Developer Review
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** Require at least two independent providers and one independent client, request→receipt→package→proposal→review interop, A→B→A loss-aware round trip, hostile containment, and accessible consent/review evaluation before 1.0 or near-RC claims.
- **Disposition:** Accepted
- **Rationale:** Local green tests do not establish independent implementability or human usability.
- **Target version:** pre-1.0
- **Target layer:** maturity gates
- **Affected artifacts:** roadmap; interop reports; conformance claims; governance
- **Security impact:** Requires adversarial deployed evidence.
- **Privacy impact:** Requires real consent/review evaluation.
- **Interoperability impact:** Defines the minimum independent proof.
- **Validation requirement:** Publish implementation identities, versions, profiles, fixtures, results, exceptions, dates, and evidence digests.
- **Status:** planned

### OCP-NR-104 — Accepted

- **Sources:** INV:§5; ARCH:§6.3; BRIEF:Working Methodology; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Build 0.4 in a new versioned release tree with source spec, core schemas, bindings, profiles, mappings, registries, conformance, examples, review data, tools, and generated dist; do not overwrite 0.2.
- **Disposition:** Accepted
- **Rationale:** A versioned tree prevents legacy builders and active snapshots from silently mutating the new authority.
- **Target version:** 0.4
- **Target layer:** release engineering
- **Affected artifacts:** releases/0.4-working-draft; archive; top-level README
- **Security impact:** Reduces source confusion and stale-tool regression.
- **Privacy impact:** Keeps historical review evidence immutable.
- **Interoperability impact:** Provides one reproducible release root.
- **Validation requirement:** Manifest path linter proves every active normative artifact is under the selected release tree.
- **Status:** implemented

### OCP-NR-105 — Modified

- **Sources:** INV:§4,§10; BRIEF:Remove Obsolete Versions; ARCH:§6
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** After the new release passes acceptance, freeze 0.2, v0.9, synthesis binaries, superseded schema work, and review inputs under explicit historical/archive boundaries; do not delete evidence prematurely.
- **Disposition:** Modified
- **Rationale:** Active-looking competing artifacts are contradictory, but preservation and checksums are needed for migration provenance.
- **Target version:** 0.4 release acceptance
- **Target layer:** workspace hygiene
- **Affected artifacts:** archive/0.2-review-draft; archive/legacy-v0.9; archive/analysis; top-level README
- **Security impact:** Reduces accidental use of stale schemas/builders.
- **Privacy impact:** Preserves provenance without shipping analysis data.
- **Interoperability impact:** Makes the active authority unambiguous.
- **Validation requirement:** Recompute hashes before moves; top-level README identifies one current release and archived items remain retrievable.
- **Status:** implemented

### OCP-NR-106 — Accepted

- **Sources:** INV:§2,§4,§5; P0:package; BRIEF:Package Validation
- **Conflict set:** None
- **Normalized recommendation:** Keep package-lock, require clean npm ci, and exclude node_modules, .DS_Store, __MACOSX, editor locks, render caches, temporary DOCX files, and analysis work from source/release manifests and archives.
- **Disposition:** Accepted
- **Rationale:** Vendored dependencies and platform metadata are non-source, non-reproducible, and can mask dependency or packaging errors.
- **Target version:** 0.4
- **Target layer:** release packaging
- **Affected artifacts:** package-lock.json; release ZIP; manifest linter; README
- **Security impact:** Reduces unreviewed dependency payload.
- **Privacy impact:** Avoids leaking local metadata.
- **Interoperability impact:** Enables clean reproducible installs.
- **Validation requirement:** Forbidden-file scan is empty in source staging and ZIP; clean extraction npm ci/test passes.
- **Status:** implemented

### OCP-NR-107 — Accepted

- **Sources:** INV:§4 ZIP verdict,§8; BRIEF:Package Validation
- **Conflict set:** None
- **Normalized recommendation:** Produce one deterministic release ZIP with one stable top-level directory, fixed ordering/timestamps, no self-inclusion, a SHA256SUMS file that excludes itself, clean extraction tests, and no Finder-created duplicate.
- **Disposition:** Accepted
- **Rationale:** The current duplicate ZIP demonstrates how packaging drift creates contradictory artifacts.
- **Target version:** 0.4
- **Target layer:** release packaging
- **Affected artifacts:** dist package ZIP; SHA256SUMS; build-release tool
- **Security impact:** Binds distribution bytes and excludes hidden metadata.
- **Privacy impact:** Avoids local filesystem leakage.
- **Interoperability impact:** Provides one reproducible package.
- **Validation requirement:** Two clean builds yield the same archive hash; zip integrity/listing/extraction/install/tests and checksum verification pass.
- **Status:** implemented

### OCP-NR-108 — Superseded

- **Sources:** INV:§3 stale builders; BRIEF:Work Directly in Source; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Use the existing stale work generators and v0.9 builders as the active 0.4 source/build pipeline.
- **Disposition:** Superseded
- **Rationale:** The old generators emit fewer fixtures, obsolete identifiers, older lifecycles, and hard-coded dependency paths.
- **Target version:** 0.4
- **Target layer:** release tools
- **Affected artifacts:** tools/build-release; tools/validate-release; legacy work scripts
- **Security impact:** Prevents regression of negative/security fixtures.
- **Privacy impact:** Prevents loss of newer privacy constraints.
- **Interoperability impact:** Ensures generated artifacts match current sources.
- **Validation requirement:** New clean build reproduces all expected inventories and legacy scripts are outside active entrypoints.
- **Status:** closed

### OCP-NR-109 — Accepted

- **Sources:** INV:§3 prose/DOCX,§8; BRIEF:Publication Quality; B0:DOCX QA evidence
- **Conflict set:** None
- **Normalized recommendation:** Capture one deterministic Markdown-to-DOCX/PDF build and run OOXML integrity, hyperlinks, headings, code/schema presence, pagination, every-page rendering, contact-sheet/full-resolution visual review, and accessibility QA.
- **Disposition:** Accepted
- **Rationale:** PDF text extraction and ZIP integrity alone can miss omitted content, clipping, broken hierarchy, or inaccessible layout.
- **Target version:** 0.4
- **Target layer:** document production
- **Affected artifacts:** build-docx tool; DOCX; PDF; document QA report
- **Security impact:** Verifies warning/status text is not omitted.
- **Privacy impact:** Verifies privacy caveats and tables render.
- **Interoperability impact:** Produces a trustworthy reader edition.
- **Validation requirement:** Every page is rendered/inspected; XML keyword/count/link/heading checks and accessibility report pass with documented exceptions.
- **Status:** implemented

### OCP-NR-110 — Accepted

- **Sources:** INV:§3 workbook,§8; BRIEF:Review Register; SYN:XLSX
- **Conflict set:** None
- **Normalized recommendation:** Treat JSON/text decision and issue data as authority; generate any XLSX review workbook as a convenience and QA source parity, formulas, validations, tables, filters, freeze panes, widths, wrapping, charts, and rendered sheets.
- **Disposition:** Accepted
- **Rationale:** The current synthesis workbook has no reproducible text source and cannot serve as the only decision authority.
- **Target version:** 0.4
- **Target layer:** review tooling
- **Affected artifacts:** decision-register.json; issue-register.json; generated XLSX; workbook QA report
- **Security impact:** Prevents formula/binary drift from changing decisions.
- **Privacy impact:** Keeps reviewer provenance inspectable.
- **Interoperability impact:** Makes registers diffable and machine-readable.
- **Validation requirement:** Workbook IDs/counts/dispositions equal JSON exactly and all sheets pass structural/render QA.
- **Status:** implemented

### OCP-NR-111 — Accepted

- **Sources:** BRIEF:Cross-Document Validation; ARCH:release gates; INV:§8; LEAD:independent determination
- **Conflict set:** None
- **Normalized recommendation:** Run release-wide checks across prose, schemas, schema URIs, examples, lifecycle/error/event/profile registries, OpenAPI, mappings, assertions, result statuses, migration claims, links, versions, filenames, and manifest hashes; any conflict invalidates the affected claim.
- **Disposition:** Accepted
- **Rationale:** Current classification and source/build inconsistencies show that component-local validation is insufficient.
- **Target version:** 0.4
- **Target layer:** release validation
- **Affected artifacts:** validate-release tool; all normative/generated components; validation report
- **Security impact:** Detects stale or broadened authorization definitions.
- **Privacy impact:** Detects disclosure/recipient mismatch.
- **Interoperability impact:** Enforces one coherent suite.
- **Validation requirement:** One clean validation entrypoint fails all broken refs, enum mismatches, stale identifiers, missing assertions, version drift, and hash mismatch.
- **Status:** implemented

### OCP-NR-112 — Accepted

- **Sources:** BRIEF:Independent Developer Implementation Review; ARCH:release gates; SEC:release gates
- **Conflict set:** None
- **Normalized recommendation:** Perform an independent developer implementation review against only published artifacts, recording ambiguous requirements, missing behavior, complexity traps, and cross-layer inconsistencies; resolve or explicitly defer every blocker.
- **Disposition:** Accepted
- **Rationale:** Author/editor understanding is not evidence that another team can implement the protocol.
- **Target version:** 0.4 acceptance
- **Target layer:** implementation review
- **Affected artifacts:** developer review report; issue register; spec/schemas/fixtures
- **Security impact:** Finds implementation shortcuts and trust-boundary ambiguity.
- **Privacy impact:** Finds ambiguous consent/disclosure behavior.
- **Interoperability impact:** Directly tests independent readability.
- **Validation requirement:** Reviewer uses no private context and maps every finding to a stable issue/disposition and release gate.
- **Status:** planned

### OCP-NR-113 — Accepted

- **Sources:** BRIEF:Security and Adversarial Review; SEC:§7; ARCH:pre-1.0 gates
- **Conflict set:** CS-CRYPTO-001, CS-IMPORT-001
- **Normalized recommendation:** Conduct independent adversarial review of selected crypto profiles, archive parser, local/remote binding, reference resolver, consent/recipient-change flow, proposal UI, identifier aliases, import sandbox, and telemetry before enabling affected claims.
- **Disposition:** Accepted
- **Rationale:** High-risk boundaries require hostile analysis beyond self-authored fixtures.
- **Target version:** 0.4 claim enablement/pre-1.0
- **Target layer:** security review
- **Affected artifacts:** security review report; availability registry; issues; profiles
- **Security impact:** Provides independent attack analysis.
- **Privacy impact:** Tests recipient, third-party, HIC, and telemetry leakage.
- **Interoperability impact:** Validates consistent fail-closed behavior.
- **Validation requirement:** All P0/P1 findings have fixes, explicit unavailable status, or bounded deferral with evidence and owner.
- **Status:** planned

### OCP-NR-114 — Accepted

- **Sources:** R1:consent UX/accessibility; R2:consent UX/accessibility; B0:human review caveat; ARCH:pre-1.0 gates; BRIEF:Publication Quality
- **Conflict set:** None
- **Normalized recommendation:** Specify machine-readable consent inputs and accessibility/display obligations, but do not claim informed consent quality until representative human testing covers purpose, recipients, retention, training, evidence/artifact views, changes, bulk proposals, and coercion/dark patterns.
- **Disposition:** Accepted
- **Rationale:** A schema can support review but cannot prove comprehension or freedom from manipulation.
- **Target version:** 0.4 and pre-1.0
- **Target layer:** human-facing conformance
- **Affected artifacts:** client declaration; consent/review requirements; manual assertions; human test report
- **Security impact:** Reduces deceptive approval and bulk acceptance.
- **Privacy impact:** Improves understandable disclosure choices.
- **Interoperability impact:** Defines display inputs while keeping UX evidence separate.
- **Validation requirement:** Accessibility/manual assertions are never auto-passed; human studies and exceptions are reported before mature claims.
- **Status:** implemented

### OCP-NR-115 — Accepted

- **Sources:** BRIEF:Final Quality Gate; LEAD:independent determination; ARCH:§7; SEC:§8
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** Do not mark the next release complete merely because files were generated; completion requires demonstrated material improvement, resolved architecture conflicts, synchronized artifacts, passing local validation, explicit unavailable evidence, independent review disposition, and clean authoritative packaging.
- **Disposition:** Accepted
- **Rationale:** The governing objective is protocol quality, not checklist theater or agreement with reviewers.
- **Target version:** 0.4 acceptance
- **Target layer:** release governance
- **Affected artifacts:** acceptance checklist; validation reports; executive summary; release manifest
- **Security impact:** Prevents unproven controls from being presented as complete.
- **Privacy impact:** Prevents untested consent/privacy claims.
- **Interoperability impact:** Requires a coherent, reproducible package.
- **Validation requirement:** Requirement-by-requirement publication audit records pass, unavailable, or deferred status with evidence for every gate.
- **Status:** planned

### OCP-NR-116 — Rejected

- **Sources:** R1:publishability recommendation; R2:review-draft recommendation; R3:approved/secure scorecard proposal; SEC:§2 publication posture; ARCH:§6.1
- **Conflict set:** CS-VERSION-001
- **Normalized recommendation:** Publish a reviewer rewrite immediately as approved, secure, independently interoperable, production-ready, or otherwise mature because its prose scorecard and synthetic tests look complete.
- **Disposition:** Rejected
- **Rationale:** A scorecard, reconstructed draft, schema compilation, and self-authored fixtures do not establish deployed security, privacy effectiveness, independent interoperability, governance adoption, legal compliance, or human acceptance.
- **Target version:** not permitted for 0.4
- **Target layer:** release posture
- **Affected artifacts:** status notice; executive summary; conformance report; roadmap
- **Security impact:** Prevents unsupported secure or approved claims.
- **Privacy impact:** Prevents untested privacy and consent claims.
- **Interoperability impact:** Keeps independent interoperability as a future evidence gate.
- **Validation requirement:** Release wording contains no approved, secure, production-ready, independently interoperable, legally compliant, or equivalent unqualified claim.
- **Status:** closed

### OCP-NR-117 — Rejected

- **Sources:** R1:Applied column; R2:reconstructed specification limitation; R3:replacement architecture; ARCH:§1,§5.1; BRIEF:Core Review Principle
- **Conflict set:** CS-CORE-001, CS-VERSION-001
- **Normalized recommendation:** Treat reviewer assertions marked applied, corrected, complete, or validated as authoritative evidence that their reconstructed schemas and architecture should replace the current 0.2 baseline.
- **Disposition:** Rejected
- **Rationale:** The reviewers did not audit the complete current artifact, R2 contains incompatible target models, and several proposed mechanisms are weaker or unsafe; the rationale is input, not implementation evidence.
- **Target version:** 0.4 review methodology
- **Target layer:** review governance
- **Affected artifacts:** decision register; architecture decisions; migration guide
- **Security impact:** Prevents unsafe crypto, bearer, sanitization, and event proposals from re-entering by assertion.
- **Privacy impact:** Prevents dossier, stable-ID, automatic-acceptance, and inferred-state expansion.
- **Interoperability impact:** Preserves the validated 0.2 base while adopting only proven improvements.
- **Validation requirement:** Every reviewer proposal is linked to an explicit independent disposition; no Applied label is used as conformance or validation evidence.
- **Status:** closed

## Coverage conclusion

This register contains 117 deduplicated substantive decisions. It covers all three distinct reviewer inputs, the governing process brief once (with files 5–8 recorded as duplicate aliases), the 0.2 prose and executable baseline, the 0.4 synthesis inputs, the v0.9 architectural branch, and the architecture, security, and package-inventory audits. The explicit rejected set closes bearer/token authority, reviewer-as-authority, core-object inflation, destructive sanitization, prose-only cryptography, DPoP-as-plaintext-control, tombstone/recipient-state deletion overclaims, mandatory CloudEvents, sensitive inferred HIC state, premature maturity claims, and stale-build-pipeline reuse.
