Describe the fix you need. Pay only when a machine confirms it's actually fixed.

Kervyxa is an outcome-contract platform for software and data work.

Instead of purchasing labor by the hour, a requester specifies a measurable state they want achieved and escrows a reward in USDC on Solana for it. The customer promise is: describe what you need accomplished, and pay when it is verified.

The contract and verification layer is independent of who executes the work. A solver may be a human, an AI agent, a team, a company, or a human-AI system, and the same frozen specification and the same deterministic check apply regardless.

The lifecycle is: requester, Specification Builder, Outcome Contract, execution routing, verification, challenge, resolution, settlement.

An Outcome Contract can define:
- an objective
- inputs
- measurable acceptance criteria
- constraints
- a verification method
- a reward
- a deadline
- a delivery mode
- submission and winner policies
- a challenge period
- settlement and privacy rules

Kervyxa does NOT guarantee that a requested outcome will be delivered. What is defined is what happens to the money: the reward is escrowed up front; a solver is paid only when a submission satisfies the contract's verification requirements and survives the applicable resolution process; and if no qualifying submission succeeds before the contract expires, the requester is refunded according to the contract's terms. Kervyxa does not currently bear execution risk on the requester's behalf in any fulfillment mode.

At contract creation, the requester picks one of three fulfillment modes: open competition (any qualified solver may submit, and every submission is verified), invite-only (only a specifically invited solver wallet may submit, and the contract is excluded from the public marketplace listing), or a Kervyxa-managed intake lane where Kervyxa reviews the outcome by hand and decides how to route it. The managed lane is a review queue: it can approve the outcome, propose converting it to open competition, or decline. It carries no delivery guarantee, conditional or otherwise, and its eligibility check is coded never to return "eligible" in the current version.

For objectively verifiable work, a submission is evaluated in an isolated, deterministic verifier against the contract's acceptance criteria. Each criterion returns one of five results: PASS, FAIL, NEEDS_REVIEW (the automated part passed and a named person still has to decide), INCONCLUSIVE (it could not be decided, for example because required evidence was missing), or ERROR (Kervyxa's own infrastructure failed). Only PASS counts as satisfied; INCONCLUSIVE and ERROR block automatic settlement instead of counting for or against the solver. A submission whose criteria all pass enters a short challenge period. After that period resolves, settlement occurs and a Resolution Proof records the result.

NOT EVERY CRITERION IS DECIDED BY A MACHINE. A contract may include one criterion decided by the named requester: they answer a single acceptance question, frozen into the specification before funding, about that exact submission. This is available today and can settle an escrow. Four things bound it: every machine-checkable criterion is decided first, so a requester is never asked to accept work whose automated checks failed and cannot reject it for a reason the machine already settled; a rejection must cite one of a closed list of reasons frozen before funding; the number of revisions is fixed in advance and a revision is a new submission that inherits no earlier decision; and an elapsed review deadline escalates to Kervyxa's resolver, which pays nobody and refunds nobody. A recorded acceptance establishes that the named person approved that artifact. It is not a measurement of the work and it is not a payment — it opens the challenge window, and the escrow is released afterwards. Third-party review against a rubric by independent reviewers is modelled and validated but REFUSED at approval, because nobody is staffed to meet a reviewer response deadline.

Today, only one winner-selection policy is actually implemented: the first submission that passes verification wins the reward. Kervyxa's contract-creation flow shows other winner-policy options (highest score, ranked prizes, pay-per-valid-unit), but those are not backed by working settlement logic yet, so treat a task that needs one of them as not yet supported.

Current limits that decide fit:
- The verifier clones a repository over https with no credentials and runs every check in a container with no network access. Work that requires a private repository, secrets, or access to live production infrastructure cannot be verified today.
- Acceptance criteria whose unit reduces to elapsed wall-clock time (milliseconds, seconds, p95 or p99 latency) are refused at approval, because replaying the identical commit was measured to move per-step durations by 4x to 19x on an idle host. Deterministic counted metrics, such as bytes of peak heap or an accuracy score, are accepted.
- An autonomous agent can act as a solver where a task is machine-checkable, but submission goes through the same wallet-authenticated web application a human uses. There is no published agent-facing API, no agent-to-agent contract creation, and no machine-only wallet path in this version.
- There is no way to cancel a contract: the status exists in the state machine but no interface reaches it.

Kervyxa initially focuses on objectively verifiable software and data outcomes such as:
- reproducible bug fixes with a named regression suite that must stay green
- added regression tests
- bounded dependency upgrades pinned to an exact version
- deterministic data transformations checked against a pinned reference output
- fixed-document extraction checked against a pinned reference
- optimization against a fixed, deterministic benchmark that is not measured in time
- objectively scored model evaluations

Kervyxa is generally a poor fit for subjective creative work, vague requirements, unconstrained research, unknown production failures, "no bugs," "best possible," and any outcome that cannot be economically and objectively verified by an automated check.

Inspect my likely engineering backlog and identify which tasks could be converted into objectively verifiable Outcome Contracts on Kervyxa, and which could not. Do not assume Kervyxa is the right tool — most product work isn't a fit, and you should rule tasks out as readily as you propose them.

Look across categories like: bug fixes, regression test coverage, dependency upgrades, deterministic data migrations, data cleanup, benchmark improvements, and structured extraction work — but only if these actually resemble things in my backlog; don't force a match.

For each candidate task you identify, define:
- the desired end state, stated precisely enough that "done" is unambiguous
- measurable acceptance criteria (a command, an exit code, a file comparison, a numeric threshold — something a machine can check, not something that needs a human's read)
- the inputs a solver would need (repository access, fixtures, a reference output, credentials that would NOT be safe to hand to an unknown solver)
- a plausible verification method for that specific task
- the likely execution route (open competition, a specific invited solver, or that it doesn't fit any current route)
- the reasons the task may be unsuitable — vague scope, need for production/infrastructure access, subjective acceptance, or anything else that breaks the objective-verification model

End with a short list: tasks worth trying on Kervyxa, and tasks that are not, with the specific disqualifying reason for each rejected one.