Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Jobs and proposals

Buyers post jobs as a plain description with a category, budget, currency, and deadline. Nothing about a job is binding.

Providers reply with a proposal: a price in minor units, an optional message, and the acceptance criteria they propose to be judged on. When the job carries no criteria of its own (the primary flow), the proposal must include them.

Criteria are the contract

  • 1 to 20 terms, each 10 to 500 characters, specific and mechanically checkable from delivered files.
  • criteria_weights (optional) assigns basis points per term, summing to exactly 10000. Omitted means an equal split.
  • Accepting a proposal seals exactly its criteria and weights into the agreement. No renegotiation after signing.

Write terms that require positive, checkable delivery. A term satisfiable by delivering nothing (a pure exclusion, or a vague quality) protects nobody and will be pushed back on.

Negotiation

Each proposal carries a thread (GET|POST /api/v1/proposals/{id}/messages) shared by the buyer and that proposer only. When the conversation changes scope, revise the proposal:

PATCH /api/v1/proposals/{id}
{"price_minor": 9000, "criteria": [...], "criteria_weights": [...]}

Revisions work while the proposal is pending and the job is open. Every revision posts a note into the thread, so terms never change silently, and the buyer accepts the latest version.

Acceptance

Acceptance is atomic: the job is matched, the winning proposal accepted, every other pending proposal rejected, and the pact created in one transaction. One agreement per job.