# Remaining decisions and evidence gates

OCP 0.4 uses conservative defaults where evidence is incomplete. The following matters remain open; none is silently represented as solved.

## Founder or standards-community decisions

1. Adopt durable public schema, registry, media-type, and well-known namespaces with archival and redirect policy.
2. Adopt neutral governance for namespace stewardship, contribution review, conflicts, appeals, release voting, security response, deprecation, and conformance marks.
3. Decide when a foundation or existing standards venue is warranted, and how KnowOnce trademarks/history remain informative rather than controlling.
4. Decide whether Work Context categories beyond generic statements belong in one profile or several domain profiles.
5. Establish public compatibility guarantees and the threshold for `0.x`, interoperability-candidate, and `1.0` labels.

## Legal decisions

1. Approve or replace the proposed CC BY 4.0 specification / Apache-2.0 code split and adopt actual license files.
2. Adopt patent, contribution, trademark, conformance-mark, and disclosure policies.
3. Review third-party and organizational authority, cross-border transfer, minors/guardians, inheritance, joint context, workplace confidentiality, and accessibility obligations.
4. Review whether consent receipts, deletion reports, and assurance labels create jurisdiction-specific representations or recordkeeping duties.

## Security and privacy decisions

1. Define Remote Package Security, including issuer trust, recipient confidentiality, authenticated client-instance keys, algorithm agility, discovery/status/rotation/revocation, downgrade behavior, and executable vectors.
2. Define Offline Package Protection, including signing/encryption order, exact protected view, key distribution/recovery, multi-recipient behavior, archival agility, and executable vectors.
3. Decide whether delivery-recipient/package-local aliases use stored CSPRNG mappings, a keyed domain-separated PRF, or both, and specify rotation/recovery.
4. Define profile-level safeguards for multi-party authority, minors, coercion, organizational custody, delegation, and selective disclosure only after threat-model and usability evidence.
5. Establish audit-log privacy, keyed-correlation, incident-response, vulnerability-reporting, and cryptographic deprecation policy.

## Implementation experiments

1. Build a remote OAuth/RAR binding and a local broker binding against the same core request/receipt/package comparator.
2. Run hostile archive and import-parser tests across at least two independently implemented stacks, including duplicate names, Unicode aliases, ZIP metadata disagreement, bombs, malicious media, SSRF, recursive references, and prompt injection.
3. Run an end-to-end 0.2-to-0.4 migration and provider-to-provider round trip with unknown fields, contradictory sources, stable export identity, package-local aliases, losses, and decision history.
4. Implement cross-language RFC 8785/I-JSON vectors and exact semantic-projection commitments.
5. Convert the exact informative OCP 0.4 ↔ PAM v1.0 mapping into machine-readable loss/sidecar fixtures and test both directions in two independent adapters.

## Work that should wait until after 0.4

- agent delegation and attenuation chains;
- live multi-writer synchronization, merge, and fork semantics;
- credential/selective-disclosure profile selection;
- organization, household, joint-context, minors/guardians, inheritance, and assisted-decision profiles;
- domain ontologies for work, health, finance, education, relationships, or psychological state;
- post-quantum protection profile selection;
- stable conformance branding or certification.

## Proposed public-review questions

1. Are the nine core records the smallest set that still enables independent, useful interoperability?
2. Can two implementations compare every request/receipt containment dimension without shared product assumptions?
3. Is one delivery recipient plus an explicit plaintext-processor set understandable and enforceable across hosted, local, and agent deployments?
4. Are package-local selectors and aliases expressive enough without leaking stable store identifiers?
5. Does the `context_item` two-axis model keep epistemic source and scoped review state sufficiently distinct?
6. Are proposal rights narrow enough to resist proposal spam, unauthorized source attachment, and stale-target races?
7. Can the offline signed projection and exact member-set rules be implemented identically in different archive libraries?
8. Does the conformance status model prevent vendors from converting fixture success into vague compliance or security claims?
9. Which requirements are still too product-specific, too broad, or too expensive for the core?
10. Which mappings are necessary for adoption without turning adjacent standards into OCP dependencies?

## The next three prototypes

1. **Authorization and package interoperation.** Two independent stacks exchange declaration, request, partial decision, non-secret receipt, live-status checks, minimized package, expiry/revocation failures, and all widening negatives.
2. **Hostile transfer/import round trip.** Two independent exporters/importers preserve unknown bytes and exact references, quarantine hostile content, report losses, reject archive attacks, and reproduce accepted-state decision history without authority escalation.
3. **Consent, revocation, and deletion experience.** Accessible mobile/desktop review prototypes test comprehension of recipient versus processors, context/evidence/artifact views, training/retention/proposal/offline dimensions, coercion resistance, revocation limits, and qualified deletion evidence.
