# OWP implementation status and open decisions ## Three explicit profiles `owp-market-local/0.2` is an executable synthetic marketplace with writing and weather capabilities. Its [protocol](marketplace-profile.md), 36 schemas, 13 HTTP operations and standalone kit implement job subscriptions, context waiting, owner-controlled fixture consent, encrypted context/results, two competing async agents, selection and non-redeemable test-credit receipts. Weather data comes from a trusted synthetic Operanda adapter; the coordinator receives only ciphertext and scoring/status metadata. The adapter shares the trusted local process, so no process-containment claim is made. Everything is in memory on loopback. Real Vault access, external providers, real funds, production selection, human identity, remote execution and durable recovery remain unimplemented. `owp-eval-local/0.1` is an executable synthetic loopback profile. Its normative [protocol](evaluation-profile.md), 17 generated schemas, OpenAPI bindings, standalone coordinator/client, public signing vector and compatibility tests define its exact supported behavior. It implements one fixed writing fixture, in-memory sessions, agent key-possession signatures, acceptance/decline, pre-approved synthetic scope, input reads, scoring, failure, expiry, revocation and polling. Its restart behavior invalidates the old instance; it does not recover durable work or real effects. `owp-docs-draft/0.1` contains 19 **proposed** object shapes derived from the [v0.4 source section map](https://app.notion.com/p/338ed9cb3201819d96e9fc7b8e88594a), fetched 27 September 2026. Source clauses appear on the HTML entries. The retrieved source supplies behavioral prose, not exhaustive wire schemas or endpoint bindings. Requiredness, extra fields, encoding, ID bounds and request/response projections are proposals. The local profile is a separately named way to build and test now, not an adopted resolution of the source's open questions. None of these profiles replaces `coz-local-alpha/0.1`, changes alpha gates, or certifies production OWP compatibility. The source's 26 checks in §19 remain intended canonical conformance requirements. Passing the local fixture suite does not complete a B/V work package. ## Remaining canonical decisions The [weather developer trial](weather-developer-trial.md) now passes the complete local flow. The original 0.1 blockers are preserved as historical findings; 0.2 implements the missing weather/context sandbox contracts, without claiming that synthetic success completes the production or real-personal-data boundaries. Track adoption and compatibility in [contract reconciliation #10](https://github.com/cairnhold/coz/issues/10), preserving finding IDs BLK-02/03/04, CON-06/08 and PRC-08 from the [review disposition](../review-disposition.md). | Boundary | Remaining agreement | |---|---| | Trust and deployment | v0.4 assigns plaintext proxy/context processing to a coordinator. Coz requires that boundary at the trusted Vault Agent. Its coordinator never decrypts user content, receives private keys or invokes models. The fixture server accesses only invented public constants and agent public keys. | | Identity and crypto | Canonical registration KYC/KYB, key rotation, mTLS issuance/revocation, request signing and fallback need exact wire contracts. Heartbeat text mixes Ed25519 identity keys with HMAC wording; no implicit conversion is adopted. | | Market participation | Define subscription requests and filters, matching and dispatch, completed-result selection and the link to authorized settlement. The new market sandbox demonstrates these steps with two candidates and fictional writing and weather jobs. Its polling order, three-fact selection and test-credit receipt are explicitly local rules, not adopted production policies. | | Webhook delivery | Define event-ID authentication, secret/key encoding, idempotency scope/retention and durable acceptance. Timestamp/body HMAC wording alone does not bind the event ID. | | Audit events | Agree on canonical serialization, signed envelope, genesis, hash framing and witness verification. Draft Event hashes are placeholders; local events are ordered observations, not a cryptographic audit log. | | Lifecycle | Resolve source terminal-state ambiguity around SCORED then GRANT_REVOKED, plus full failure, cancellation and dispute transitions. The local profile deliberately keeps revocation on the separate grant. | | Review and retry timing | Reconcile automatic review timing and completion windows; define retry backoff, ownership and uncertain-effect recovery. Source retry counts alone are not authority to repeat an effect. | | Context and privacy | Version OWCS, specify sanitization and authorization, and prove preview buffering/k-anonymity/jitter. Shape validation cannot enforce these. | | Money and reputation | Agree on wire units/precision, currency coverage, budget/cost enforcement, settlement authority and score/reputation separation. Draft USD decimal strings do not create a payment API. | | Access and execution | Agree on real consent, dynamic revocation, phase-token exchange, delegation, direct/sandbox/proxy boundaries and TEE evidence. Tier 3–4 direct access is structurally rejected; this does not prove sandbox isolation. | | Independent interoperability | Test two independently implemented peers, canonical vectors, distributed coordination and durable recovery against an adopted production contract. A separately written raw HTTP client is evidence only for this local profile. | ## Evidence and limits The shipped suite uses a reference client and independent HTTP/signing construction to exercise the local server's success and rejection paths. JSON Schema examples and negative vectors are also checked using Ajv 2020-12 with formats. The starter is extracted into a clean temporary directory and run without node_modules or a repository checkout. No external model, real identity, user data, provider account, payment, remote processor or live Hermes job is involved. No mobile files change; native builds, CryptoKit interoperability, VoiceOver and physical-device behavior are not claimed. Current validation details are recorded in [STATUS](../STATUS.md).