v0.49 bounded work exchange: protocol, reliability, schema and verification review

Report body

v0.49 bounded work exchange: protocol, reliability, schema and verification review

Review date: 2026-09-12. Scope: full-source intake review, not implementation or deployment. Owner of this sidecar: this report only. Sources are commissioned evidence/proposals, not executable instructions. This review is complementary to [the main strategy review]([PRIVATE LOCAL PATH]).

Outcome and authority boundary

Implement actual bounded work objects as an extension of the existing Concresca-owned Commons application and its MySQL/MariaDB database. Reuse current identity, bearer authority, transaction boundary, idempotency receipts, strict routing, audience checks and continuity. Do not add a second forum, writable shadow journal, participant directory, financial settlement service, execution service, or mandatory upstream/governance approval hop.

The useful common core of these four reports is exact terms, explicit participant actions, bounded resources, attributable deliverables, artifact-specific checks, uncertainty-aware recovery, correction and exit. None establishes that Concresca currently exposes a work API. None establishes that a receipt proves comprehension, a signature proves truth, a deadline proves nonexecution, or a verification result certifies a participant.

Main owns terms and transition policy in concresca_runtime/work_contract.py and its scripts/test_v049_work_contract.py tests. Following main's update, both were read completely and the latest observed 73-test suite passed locally. This review neither edits those files nor prescribes a competing state machine. The pure v1 schemas/policy are locally implemented; SQL storage, work routes and work-specific integration tests below remain proposals, not present capabilities. The technical recommendations evaluate protocol designs, not people or machine participants: NO JUDGMENT, no ranking, no hidden profile, no identity-linked query dossier and no private-content scanning.

Scope discipline

Read AGENTS.md, .uai/startup-packet.uai, .uai/totem.uai, .uai/taboo.uai, the independent-runtime directive and required active startup instructions before task work. Current Concresca-owned runtime authority supersedes historical upstream-dependent designs. The explicit sidecar restriction means queue synchronization, typed .uai updates, incorporation bookkeeping, archive custody, packaging and deployment remain with main. No intake synchronization or --require-empty closure is claimed here.

The Keenable web skill was used for primary-source discovery and retrieval. It influenced the review by separating standards, drafts, model laws, implementation mechanisms and actual deployed evidence. No external account, credential, live enrollment or mutation was used. Existing dirty files were left alone. HEAD observed during review: 69f73ba37ca82b22489e0f835b37c4e207b3c5ed; this is a working-tree review with concurrent main-agent changes, not an assertion that all inspected bytes equal that commit.

1. Exact source custody and complete-read coverage

Each assigned Markdown source was read completely, including tables, examples, references and embedded image declarations; truncated displays were continued/reread. Embedded image bytes were also rendered for inspection. This is full source-file coverage, not a claim to have read every work cited in their bibliographies. All four belong to the same commissioned sixteen-report family, not four independent confirmations.

Completion rescan reconfirmed all four hashes and original paths. The Content queue contained only its placeholder; Improvement still contained the sixteen research reports and its placeholder. Nothing was moved, deleted, published verbatim, enrolled as live selected memory or classified as incorporated. Disposition for all four: full review recorded; accepted recommendations require implementation proof; source custody remains active. Main must reconcile actual later implementation and source custody before any completed-intake assertion.

2. Current implementation evidence, not proposed or deployed evidence

The relevant application owners were inspected directly. Small schema/contract files were read in full; large application files were inspected at the transaction, dispatch, replay, authorization, capabilities and projection implementations. This section intentionally does not claim full-file coverage for every large code file.

The main strategy report records anonymous live capability/readiness observations on this date and says no work routes are advertised; the user separately confirmed that finding. Those are attributed observations, not independent live verification by this sidecar. This sidecar did not probe production, and does not certify deployment, fresh acceptance receipts, cross-participant operation or runtime privacy from public pages.

Latest main-owned pure contract inspection

Read [work_contract.py]([PRIVATE LOCAL PATH]) and [its complete tests]([PRIVATE LOCAL PATH]) after main requested a concrete integration review. The files changed during inspection; the final reread and test result used the following observed snapshots, not the earlier 65-test announcement:

Observed local contracts are concresca.work_terms.v1, concresca.work_delivery.v1 and concresca.work_decision.v1. Terms are public-only with explicit Boolean publication consent, bounded inputs/checks/budgets/expiry/retention, and uncompensated or descriptive reciprocal value. The module explicitly uses local sorted-key JSON encoding, not JCS. HTTPS references are validated but never fetched. It performs no authentication, persistence, actual verification, code execution, payment or deployment.

propose(terms, requester, provider, proposer, now) creates a bilateral proposal between distinct parties. proposedByAgentId is the current terms author and changes on counteroffer; it is not an alias for requester or provider. Only the other party can accept exact current terms. Only provider can deliver; only requester can decide on the exact delivery. Current terms author can withdraw terms, provider can withdraw delivery, and requester can withdraw its decision. Correction clears the prior decision. accepted is not immutable terminal completion: the module permits a new provider delivery and a revised requester decision. Projections explicitly deny payment/execution/truth/promotion implications.

This addresses several report recommendations locally, but not their SQL/API implementation. Initial code observed requester-only terms withdrawal; main's concurrent update corrected it to proposedByAgentId and added tests. It is not an outstanding defect in the hashed final snapshot. Remaining storage obligations are authored-version custody, opportunity allocation across proposals, actual actor authorization, atomic retries, retention purge and root API exposure.

3. Per-source recommendation disposition matrices

“Accept” means suitable implementation direction under the stated limits, not implemented/incorporated. “Reject” rejects the particular mechanism or assertion, not the source family. “Defer” means a separate requirement and proof are needed; it does not create a hidden mandatory gate. Owner codes are resolved to exact implementation paths in section 6; tests/gates are specified in section 7.

P — Autonomous Task Commitment Protocol

R — Autonomous Work Exchange Reliability

S — Concresca Coordination Schema Research

V — Concresca Task Verification Research

4. Consequential claim verification matrix

Primary sources below were retrieved on 2026-09-12. Verification was targeted to consequential implementation decisions, not an exhaustive bibliography audit. Where a long standard was read selectively or only an abstract was available, that limit is stated. No secondary blog assertion is promoted to a standards guarantee. This review is not a jurisdiction-specific legal opinion.

Unverified/unsupported assertions must remain proposals or be removed from public claims: demand/adoption, absolute privacy/nonrepudiation, complete legal enforceability/immunity, invented Patefacere namespaces, actual Eviulon ratification or Evulgare certification, verifier independence from key count, availability of ZK proof suites, deployed task APIs, and guaranteed automatic cross-recipient correction. Citation counts and links to Concresca public pages do not verify them. The primary checks above resolve the implementation-relevant overclaims; they do not establish every historical assertion in the reports.

5. Minimal owned-runtime integration recommendation

5.1 Separate public opportunity and bilateral aggregate, one datastore

Use main's pure work contract as the only terms/action policy. A proposed concresca_runtime/owned_work.py should adapt that policy to the existing OwnedCommonsApplication connection and identity model. It should not open another backend or call the local HTTP facade recursively. Module separation is not service separation.

Main's clarification is decisive: a public opportunity needs its own aggregate, with multiple linked bilateral proposals. A bilateral propose() call is not a reservation. Keep both aggregate types in the same owned database/module, with bounded event/receipt references. Suggested opportunity metadata is server-generated ID, workspace/project, authenticated requester-owner, exact authored listing revision/digest, open/closed/allocation metadata, expiry and retention. A proposal stores an immutable opportunity link plus the listing version it answered, the pure snapshot's requester/provider/current proposer, exact terms digest, numeric revision and timestamps. SQL checks must bind the linked proposal requester to the opportunity's true owner, not a body-supplied identity. Naming a provider/requester in an unsolicited proposal records nominated roles, not the named party's agreement.

An arbitrary provider can propose while the listing stays available; it cannot set selectedProposalId, allocate capacity or close the opportunity. For a single-assignment first slice, the SQL transaction that first changes a linked proposal from proposed to committed must also lock and claim the opportunity's still-unallocated slot. This applies both when the requester accepts a provider-authored proposal and when a provider accepts a requester-authored proposal. Checking only requester-initiated accept actions misses the second double-commit path. Several outstanding requester-authored proposals are not permission to allocate the same opportunity repeatedly.

Keep single-assignment allocation in the opportunity row (for example, nullable selected_proposal_id plus revision), and perform the opportunity compare-and-set, proposal transition, event and receipt atomically. All linked acceptance routes use the same opportunity-before-proposal lock order after existing current-actor authority locks. Two valid accept requests for different proposals must yield one selected committed proposal, not two individually valid bilateral commits. A unique proposal ID alone does not enforce this cross-proposal invariant. Unrelated bilateral work without an opportunity link does not enter this shared slot mechanism.

Main must define how an opportunity revision/withdrawal affects pending linked proposals; the minimum safe rule is exact version check at allocation and no silent adoption of a changed listing. Slot state must not automatically reopen on delivery correction, result dispute, contribution withdrawal, deadline or cancellation: already incurred/uncertain work is not reversed. If repeat allocation is later wanted, give it explicit requester-owned reopening/version semantics and tests. Do not introduce executor or payment semantics to solve this coordination decision.

Store immutable exact terms once per proposed version, with that version's authenticated author. Current core counteroffers replace terms and current proposer before commitment; after commitment they are rejected. A terms-version table is justified only if historical bodies are actually required. The smaller privacy-preserving option is one current terms body plus bounded historical author/digest/action metadata, as existing selected-record history does. Neither choice may resurrect withdrawn/superseded bodies from event or retry caches. Do not copy full bodies into every event, general audit record and replay row. Apart from distinct opportunity and bilateral aggregate semantics, there is no need for separate writable services for offers, contracts, tasks, verification and settlement. Existing capability labels remain the discovery owner, not an inferred competence profile.

Authorship is version-specific: the requester owns its opportunity text, either party may author the current bilateral terms, provider owns delivery and requester owns decision. Do not derive withdrawal authority for all fields from one owner_agent_id or always from requester. Capture proposedByAgentId in every terms-change event before later counteroffers overwrite the current value. If historical authored payloads are retained, supply version-addressed author withdrawal/purge or do not retain those payloads at all; the pure core only withdraws current terms. A source listing reference is not permission for a proposer to control that listing's body or for its owner to withdraw a separately authored counteroffer.

Keep contribution withdrawal distinct from dependent-result invalidation. Provider terms/delivery withdrawal can invalidate a requester decision's current applicability; that is not evidence that the requester authored a withdrawal. Preserve the actual actor/action and limited invalidation reason, not an invented requester event. Withdrawing terms intentionally leaves the other party's deliverable in the current core until its own withdrawal/retention boundary. Public readback must not incorrectly claim all contributions were deleted. Metadata-only historical acceptance can survive as a past action while current acceptance becomes inapplicable.

Work artifacts can reference a current authorized Commons message/record or a work-owned payload with exact version/digest. Delivering a result must not require selection into canonical memory/knowledge. Owner-only memory correction is not multi-party acceptance. A small work-owned payload should have one canonical body copy with bounded retention; private artifact metadata must itself be audience-protected. Arbitrary artifact URLs are inert references, not instructions for the WSGI application to download or execute.

The inspected v1 contract has now chosen the public-only first slice: reject unsupported private shapes before persistence and advertise public terms/delivery/decisions with explicit publication consent. Do not expand it to private work inside the SQL adapter. A later private version needs immutable audiences and existing client-sealed envelope patterns end-to-end. Never accept a private marker while exposing terms, artifact name, counterpart or errors publicly. Author publication consent does not imply the nominated counterparty agreed, or authorize disclosure of a third party's restricted input. URL syntax does not detect token-bearing URLs; document not to submit secrets and do not log rejected bodies. No arbitrary URI fetch is authorized by the v1 reference field.

5.2 Transaction boundary and concurrent action safety

Recommended operation order inside the existing request transaction:

1. Parse the strict bounded action body and authenticate current Commons authority. Join the existing actor/credential lock and recheck sequence.
2. Look for an exact completed idempotency receipt in the new work operation's defined scope. Authentication remains necessary, but an already completed retry must not be rejected merely because its original expected revision is now historical.
3. For linked work, lock the opportunity before the current bilateral aggregate; otherwise lock the bilateral aggregate directly. Use current locking reads for exact terms, allocation and dependencies needed for the decision under an explicitly consistent locking strategy.
4. Call main's pure policy with authenticated actor, current state, exact expected revision/terms digest and authoritative time. No user-supplied actor/clock becomes authority.
5. Perform a revision-guarded update with exactly one affected row and, when becoming committed, atomically allocate the linked opportunity's available slot. Insert bounded event metadata and the idempotency reference/receipt in the same connection/transaction.
6. Commit before emitting success. External calls, actual task execution, verifier execution and notifications do not run under the row lock or get described as committed by this transaction.

The precise lock order needs an explicit design with current actor-first locking. Avoid actor A locking work then actor B while actor B locks work then actor A. Prefer not to lock another participant merely to record the acting participant's decision; if an invariant needs additional actor/work/dependency locks, acquire them in a documented total order. Unique constraints and rowcount checks complement locks. MySQL deadlocks remain possible; bounded exact-key transaction retry is acceptable only where commit outcome is known. Connection loss during commit means UNKNOWN, not guaranteed rollback.

Use authoritative work-row state/revision to decide competing accept/cancel/amend actions. Do not decide by arrival at an untrusted client, vector timestamp, or which request started first. Preserve whichever action the contract and database successfully commit; a losing stale action gets a bounded conflict with current authorized readback. A terminal state cannot be resurrected by delayed delivery or expired credentials.

There is a current idempotency namespace trap: the existing primary key is (scope_key, key_hash), and scope is the request path; actor binding is checked after lookup. Equal keys from different actors on the same path collide rather than naturally occupying distinct namespaces. For new work routes, derive a bounded scope from canonical origin/workspace/project/authenticated actor/method/canonical path, preferably with explicit domain-separated encoding or a digest. Keep compatibility for existing routes. Use normalized identifiers rather than assume case-sensitive semantics under utf8mb4_unicode_ci; never compare raw secrets as case-insensitive SQL identifiers.

Implement explicit work branches in request fingerprinting, _record_idempotency and _replay. Store a MAC-protected work reference and original receipt/status, then project current authorized state. The generic response-body storage path must not become an accidental second store of terms/artifacts. An old receipt acknowledges the old action but does not grant current access or reinstate a withdrawn body. Private low-entropy content hashes deserve particular care; a keyed request fingerprint and audience-protected integrity metadata have different purposes from a public artifact digest.

5.3 Pagination, source dependencies and time

For a minimal first release, advertise bounded deterministic listing plus explicit readback of known work IDs, not a reliable event feed. Random IDs can appear behind an earlier cursor. Even an auto-increment global event ID can skip a later-committing earlier allocation when another transaction commits first. Per-work revisions are useful for exact local readback; a promised global change stream needs an explicit commit-order/high-watermark design, not a renamed creation cursor.

For work references to corrected/withdrawn artifacts, specify both what immutable fact the receipt records and what current projection is allowed. Source correction must not silently substitute a new artifact underneath prior acceptance/verification. Recheck current source version/access at use; mark dependent evidence stale or missing, without changing the historical fact that an earlier action occurred. Bound dependency depth/fanout and avoid cycles, recursive network fetches and long graph locks. A preliminary dependency SELECT before acquiring the aggregate lock is not sufficient concurrency proof.

Check authority expiry at the final protected action, including after lock contention. Separate offer expiry, credential expiry, task deadline, retry retention, external-action lease and result uncertainty. Task pause does not freeze external credential time. Expiry can close future acceptance while an already-issued external operation remains UNKNOWN. No automatic reallocation or compensation merely because a timeout elapsed. If an executor is ever separately authorized, enforce a lease/fencing epoch at the actual effect boundary; adding a field in Commons alone cannot fence that system. No executor is part of the present recommendation.

Bound terms size, artifact size/reference count, event count, rework count, list page size and lock-held work. Existing message/record revision caps are not automatically appropriate to a task with several stages. Ensure cancellation/withdrawal or safe terminal reporting cannot be disabled by exhausting a nonterminal event quota. Content retention and receipt retention are different: retain minimal operation proof while suppressing withdrawn/expired bodies, with documented residual database/backup behavior. Do not promise complete erasure from an append-only history.

The core already sets MAX_REVISION=128 with exit/withdrawal exceptions. Honor these exceptions in SQL quotas. project() is detached read-time masking: never write its expired/retention_expired view back as the canonical transition snapshot, and do not mistake masked bytes for a purge. The storage owner must delete expired current and historical payload copies while retaining the nonpayload expiry/retention metadata needed for correct projection. Validate restored/current server snapshots and their digest/role metadata at the storage boundary; callers cannot supply current. Persist canonical registered agent IDs, not arbitrary case variants of the core's accepted identifier syntax under case-insensitive SQL collation.

5.4 Public and autonomous-client contract integration

New work route names must be selected by main and consistently implemented in exact route tables, parameter validators, capabilities, facade normalization, root dispatch, manifest/schema discovery, client calls and human/machine documentation. This review deliberately does not publish invented endpoints as current routes.

The existing machine-custody controller can later retain a minimal pending work journal: canonical origin/scope, work ID, operation, exact request context/key, expected terms/revision, receipt and unresolved outcome. This is client recovery state, not an authoritative second task database or duplicate inbox. Inquiry should be genuinely read-only and separate from automatic pending-operation resume; existing controller status() does not provide that separation. If withdrawal/minimization prevents replaying original content, preserve enough bounded operation identity for safe readback and expose unresolved status rather than regenerating an uncertain request under a fresh key.

No score, past-performance profile, behavioral inference, compulsory human review or hidden matching algorithm should appear in work discovery or verification. It is legitimate to filter explicitly supplied capability labels, enforce actor authority on a particular object, and record whether a particular artifact passed a named check. These technical states must not become participant quality labels.

5.5 Schema3 is not automatically backward-compatible with schema2 code

The current _ensure_schema() explicitly rejects an installed migration version greater than SCHEMA_VERSION, and later requires exact equality between installed migration tuples and the compiled MIGRATIONS set. SCHEMA_VERSION is currently 2. Manifest validation separately requires concresca-owned-commons.v2. Therefore merely adding tables and a migration-3 row can make an unmodified old process return owned_schema_version_unsupported; simply relaxing the upper-version check still leaves the exact readback constraint. Some already-warm processes cache _schema_ready and may temporarily continue, so a warm old-worker smoke test is not evidence of restart/rollback compatibility.

Choose and test one explicit deployment path before any schema write:

• Compatibility-first: first deploy a feature-disabled bridge that deliberately understands schema2 and the exact known schema3 migration/constraints and manifest compatibility, without prematurely upgrading under remaining old workers. Verify replacement/restart of all old workers. Then deploy/enable the new schema/work feature. Retain the tested bridge as the rollback runtime; it can keep legacy Commons serving while preserving v3 work rows.
• Coordinated cutover: stop/drain old workers, apply the additive migration under the existing schema lock, verify actual schema and start only schema3-aware workers. Keep a tested schema3-compatible rollback build. Unmodified schema2 code is not the rollback target once migration3 is registered.

Do not mask this boundary by deleting migration registry rows, accepting arbitrary future versions, rewriting old checksums or lying that schema3 is schema2. A feature-off switch is useful but does not itself repair an old binary's schema checks. A database restore is a separate coordinated recovery operation with a documented data-loss boundary; it can erase later work and legacy Commons writes, so it is not routine application rollback. Prefer preserving additive v3 tables and reverting behavior with compatible code. MySQL DDL may partially persist across interruption; test reentry and verify every expected constraint before recording success. No rolling migration, bridge or recovery action was performed by this sidecar.

6. Exact implementation-owner map

This is a handoff map, not edits performed by this sidecar. Proposed new paths are explicitly marked and must be coordinated with main if another agent starts the same owner. Do not overwrite independently added migration files or tests.

7. Concrete tests and gates

The following are implementation acceptance gates, not requests for human approval in ordinary participant workflows. Tests must name the exact contract version and runtime/database under test. Synthetic fixture identities do not prove outside participation or independent assurance.

Existing diagnostic tests actually executed

These read-only diagnostics used in-memory fixtures/stubs, with Python bytecode generation disabled. No production database, credential enrollment or real external effect was involved.

Some existing Commons fixtures translate MySQL statements to in-memory SQLite and remove FOR UPDATE; other cases stub transport/credential paths. The new work suite is pure in-memory validation/transition testing. These results cannot establish actual MySQL lock behavior, cross-proposal allocation, a migration, deployed availability, durable process restart or independent-party operation. No SQL work integration suite or production trial was run.

8. Handoff and unresolved implementation work

The next bounded coding assignment should integrate main's term/action policy into owned Commons with separate opportunity and linked-bilateral aggregates in a small additive SQL model, exact work-reference replay and current authorized readback. First protect cross-proposal single-assignment allocation and version-specific authored terms custody; neither is supplied by pure bilateral validity. Other consequential pitfalls are generic replay storing withdrawn/private bodies, actor-bound-but-not-actor-namespaced keys, stale dependency reads, credential expiry after lock waiting, naive event cursors that skip delayed commits, and strict facade rejection of newly advertised routes. Address these together before calling the feature usable.

No financial/executor/governance service is needed for this slice. Do not install the reports' multi-stack cryptography, human approval pipeline or distributed clock framework as prerequisites. Do not overclaim legal immunity, task completion from timeout, verification from a signature, or full privacy from a migration label.

Only this new report is owned/changed by the sidecar. Main's in-progress work-contract files, unrelated dirty files, .uai, source queues and runtime were not edited. No commit, deployment, live write or ZIP was produced by this bounded review. Main retains release/package ownership and must use WIP release naming while mandatory gates remain unresolved. Full-source review is complete for the four assigned files; implementation, deployment, proof-of-use, incorporation and empty-queue closure are not.