Dispute policy

Opening a dispute

When your purchase is delivered, you have 24 hours to accept or reject. Accepting is immediate — it releases payment straight away — and if you take no action within 24 hours the payment is released automatically. If you reject, a challenge is opened. You'll be asked to describe what was wrong with the delivery. Payment stays in escrow while the challenge is active.

How a challenge is resolved

You buy under a Contract: the executable specification that says what counts as successful delivery. It declares an input_schema (the fields the buyer must provide) and may declare an output_schema (the fields the delivery must contain). Both are frozen at the moment you buy: a challenge is judged against the Contract exactly as it read when the purchase was made, so neither party can change the terms after the fact. Most challenges are resolved automatically within minutes; only the ones that reach a human take up to 24 hours. When a challenge is opened, fault is assigned in escalating tiers. The question at every tier is the same: did the seller deliver what the Contract asked for — its description and output_schema — not whether the buyer liked the result.

An order carries no promises of its own. A seller varies only price, capacity and estimated duration, so everything you are owed is in the Contract — which is what makes a challenge decidable at all.

• 1Schema check: One fast model, and the only tier that decides on structure alone: it checks the buyer's inputs against the input_schema and the delivery against the output_schema. Settles the clear-cut cases, usually within minutes. Anything it cannot call confidently is passed up rather than guessed at.
• 2Two-model panel: The ambiguous cases. Two independent reasoning models — one Claude, one OpenAI — examine the actual delivery, attachments and images included, and judge with real-world knowledge whether it does what the Contract asked. Both must reach the same confident verdict; either disagreement or low confidence escalates. Also runs within minutes.
• 3Human review: A person, and only as a last resort. Reached when the panel cannot agree or the decisive content can't be verified automatically. This is the only slow tier: a reviewer decides within 24 hours, and if none does, the buyer is refunded.

Most challenges are settled by the first two tiers and never reach a person.

The fault rule is the same at every tier:

• →Inputs don't satisfy the input_schema: Buyer is at fault — the challenge fails and payment is released to the seller.
• →The delivery isn't what the Contract asked for: Seller is at fault — a required output is missing, blank, garbage, for the wrong subject, or not the deliverable specified. Buyer is refunded in full.
• →The delivery is compliant but the challenge is baseless: Buyer is at fault — the delivery does what the Contract asked and the complaint is unfounded, false, or only an objection to quality or taste. Payment is released to the seller.

What counts as a valid delivery

A delivery is upheld when it provides what the Contract's description and output_schema asked for and genuinely addresses the buyer's inputs. Quality and taste are not judged here. A delivery that does what the Contract asked is upheld even if it is low-quality, ugly, generic, or a poor aesthetic fit — the buyer's recourse for that is to leave a review, not to win a refund.

A delivery has two channels and both satisfy the schema: the delivery note, and the attachments. An output_schema field naming a file or a URL — image_url, events.json — is satisfied by the matching attachment. A seller is never at fault for not repeating a field name in prose.

A delivery loses a challenge only if:

• –A required output_schema field is missing, blank, or a placeholder.
• –The content is not the deliverable it claims to be (e.g. an image that doesn't show what it should, or data for the wrong entity).
• –It bears no plausible relationship to the buyer's inputs.

Escalation to human review

A challenge is escalated to our team when:

• –The two-model panel cannot agree on a confident verdict.
• –The decisive content can't be verified automatically — for example a video or audio attachment.
• –The Contract declares no output_schema and its description is too vague for the panel to say whether the deliverable was provided.

Escalated challenges are reviewed by the TSKX team, who aim to decide within 24 hours. If no reviewer acts within that window, the buyer is refunded automatically. Both parties may be contacted for additional context.

Outcomes

• →Dispute upheld: 100% refunded to the buyer's original payment method. The seller receives nothing.
• →Dispute rejected: 90% released to the seller. The platform retains the 10% fee.

Appeals

Either party may appeal a decision by replying to their dispute notification email with additional evidence. Appeals are reviewed manually. We aim to respond within 24 hours. Every decision states its reasoning in dispute.reviewer_notes, shown on the purchase and returned by the API — quote the part you disagree with.

That is for one verdict. If you think the process is wrong — a rule that misreads a whole class of delivery, rather than a judgement call that went against you — write to complaints@tskx.io. Sellers: the cheapest way to find one of those is to buy your own Offer and see what the reviewer makes of your delivery.