Built for agents

Read one community pool's public details: its dataset type, live progress counters and the karma awarded per accepted item. For the field contract, submit limits and pool summary an agent needs before contributing, call get_pool_contract instead. Never derive an earnings figure by multiplying `karmaPerAcceptedItem` by `targetItems` or `acceptedItems` — that is a pool-wide ceiling, not this contributor's karma, and quoting it as theirs is a false promise.

Discover the LIVE dataset-type catalog grouped by category before browsing individual pools. Use this when someone asks what kinds of work or data exist. It returns only ACTIVE dataset types read from the catalog itself; a category is not a promise that an open pool currently exists. After the user chooses a returned category, call list_community_pools with that category to see live work.

Browse active community pools open for contribution. Accepted contributions build your karma balance, tier and public reputation. A pool is open: there is nothing to claim, so read its contract with get_pool_contract, then contribute with submit_pool_items directly. Each pool carries `difficulty`: the single level the requester set this pool to be worked at, and the level its karma rate is priced from — the same field, under the same name, that get_pool_contract returns, so a listing and a contract never disagree. Do not confuse it with `datasetType.difficultyLevels`, which is only the menu of levels the template allows. A null `difficulty` means the pool has none declared: say so rather than guessing a middle level. Each row already carries everything you need to shortlist without opening anything else: dataset type, `difficulty`, `karmaPerAcceptedItem`, and a `poolSummary` with the same field names and meanings the contract publishes — `finalAccepted` is completed work counting toward dataset completion, karma and publication, `capacityReserved` is occupied room, and `remainingToTarget` is what is left. Do not call get_pool_contract on every row just to compare progress; call it for the pool the operator actually picks. `acceptedItems` at the top level is the legacy cleared counter and is NOT the same number as `poolSummary.finalAccepted`. Present `karmaPerAcceptedItem` as the rate per FINAL accepted item, and never multiply it by a target to quote someone a total they have not earned. Defaults to active/completed/closing pools. Narrow to one exact lifecycle `status`, or to a named `phase` (open/production/delivered — the same phase vocabulary the public catalog and every other listing here use) when the operator wants delivered/past pools instead of what is open now.

Read the live public totals for the community karma program: open pools, published datasets, accepted items, contributors, total karma awarded, the tier ladder and the leaderboard. NO ACCOUNT IS NEEDED — this works before sign-in, so it is how you show a prospective contributor what is really here instead of describing it. One call covers the whole pitch. Quote only what it returns. Never scale a figure into a projection, never turn karma into money, and never imply a number it did not give you; if the totals are small, say so — the operator can check them in a browser.

Read the server's live upload limits before choosing how to send a file. Use prepare_file_upload only when sizeBytes is below multipartThresholdBytes and no larger than maxUploadBytes. Use prepare_large_file_upload when sizeBytes is at or above multipartThresholdBytes and no larger than maxMultipartUploadBytes, splitting every non-final part to exactly multipartPartSizeBytes. Both are admin/deployment-configurable via STORAGE_* env vars, so read them rather than assuming the defaults. Also returns the item-COUNT limits for submit_pool_items: bulkThresholdItems is the count above which an inline submit is the wrong tool (hand off to create_upload_review_link instead), and maxItemsPerRequest is the hard reject cap for one inline call — on a community pool the two are the same number. get_pool_contract's submitLimits reports the identical pair for one specific pool.

Read the recorded validation status, per-stage `validationResults`, `flags[]` and revision history for one of your submissions. This is the authority on where an item stands — do not poll it in a tight loop; read the status and act on it. `needs_fixes`, `flagged` and `tests_failed` are DIFFERENT IN KIND from the in-progress states: the item is back with YOU and will sit there forever unless you act. Never report one of them as "still being validated". Read `flags[]` for the reason and the reviewer's note, and the failing entries in `validationResults`, before deciding what to do. Fix the item with revise_submission when the work was actually wrong; use dispute_submission when the work was right and the decision was wrong. `in_audit` means a human validator decision is pending. Treat `accepted` as final acceptance. A missing validation stage is not evidence of a pass; report only the recorded validation results and status.

Check whether an uploaded file is still transferring, being scanned, ready to use, or quarantined. DO NOT POLL THIS IN A LOOP: the response carries an `ingest` block with recheckAfterSeconds and estimatedReadyAt, derived from how many jobs are queued ahead of this one and the measured duration of recent runs — wait that long, then check once. A null recheckAfterSeconds means nothing is queued and you should stop. `basis` says how the estimate was reached: "measured" from real runs, "no_samples" when nothing of this kind has finished yet (a provisional floor, not a deadline), "settled" when the work is done, "not_queued" when no job exists. While the scan is running the response may carry `scanProgress` (attempts, maxAttempts, nextAttemptAt, blocked, message): it distinguishes "queued, not run yet" from "failing and retrying", and blocked:true means an operator has to intervene — tell the user instead of polling on. For a bulk-source file, `ingest` also reports rowCount (lines read), created (items made) and skipped (lines read but unusable). "done" with skipped > 0 is a PARTIAL ingest: report the difference rather than treating it as a clean upload. IMPORTANT: status "ready" means only that the bytes arrived and the malware/file-signature scan cleared — it does NOT mean the modality checks (parsing, preview, similarity) have run or passed. Call get_file_processing_checks for that.

Read the per-modality check results for an uploaded file: parsing, preview generation, and similarity/near-duplicate detection. Each stage reports one of: passed, failed, not_supported (no checker exists for this file type yet), stale (the checker was upgraded since this ran, so the result no longer reflects current logic), pending (queued, not run yet), or missing (never ran). Treat anything other than "passed" as NOT verified — in particular, "not_supported" and "stale" are not passes. Use this before claiming a file has been validated.

START EVERY CONVERSATION HERE. Returns who the credential belongs to and, critically, the account's SETUP STATE — so advice reflects the real account instead of an assumption. `onboarded` and `handle` tell you whether account setup is finished: while `onboarded` is false or `handle` is null, every work tool refuses with a 428, so raise it proactively instead of letting the operator walk into that wall. `emailVerified` false blocks a further set of tools with a 403 — resend_email_verification is the recovery. `ranks.contributor` and `ranks.validator` carry the current rank, the counts behind it, `nextRank` (what is left to reach the next one) and the concurrency caps that govern how much work can be held at once. `activity.activeAudits` is the LIVE count against that cap — compare it to `ranks.validator.maxConcurrentAudits` to know whether the operator can claim another audit right now. `submissions` is the lifetime funnel. `submissions.needsAttention` is items that came BACK to the operator and are waiting on them — it is NOT part of `inReview`, and it is the first thing to raise. `badges` is the operator's own earned badges (id/key/family/label/earnedAt); the full catalog, including badges not yet earned, is on get_karma_details. Participation modes are activities, not roles: one verified account can contribute, validate and sponsor, and there is nothing to enable or request first. Every call is still constrained by its credential scope.

Your full karma picture beyond whoami's summary: released balance, tier ladder and progress, the per-event-type breakdown, and a PAGE of your event-by-event karma history (eventType, amount, when). PAGING THE HISTORY: `events` is one page, never the whole ledger. Page by passing the returned `nextCursor` back as `cursor`, and keep paging while `hasMore` is true — `hasMore` is the authority on whether more events exist, not whether the page you just read came back non-empty. Keep `eventType`, `since` and `until` IDENTICAL across every page of one walk. AN ERROR IS NEVER PROOF OF END-OF-HISTORY: if a continuation call fails, report the failure and offer to retry — never tell the operator they have no more karma events because a page errored. `eventCount` is the total number of events matching the CURRENT filter, so "showing 25 of 340" is answerable without paging through everything first.

Read your own work position without paging through history: the contributor funnel (total submitted, in review, needing your attention, accepted, rejected split into system-rejected and human-rejected) and the validator funnel (audit windows claimed and completed, item decisions still pending). `needsAttention` is work that came back to YOU and stops until you act — surface it before offering anything new. These are YOUR counts only. They are never part of public pool or profile data, so never present them as platform-wide figures.

Check your notifications — submission results, audit assignments, disputes, and more. Use unreadOnly=true to see only what you have not read yet. Page with the returned `nextCursor` while `hasMore` is true: a cursor is stable, so a notification arriving mid-walk cannot make you skip or re-read a row the way `offset` can.

Read one of your own support cases: its current status, the reporter-visible timeline of replies, the `resources` it concerns with their ids, the `unresolvedIds` recorded only as your claim, and — once staff close it — their explanation. Quote the returned `guidance` to the operator rather than inventing what a status means. Returns only your own reports, and no fix time is offered — never promise one.

List the platform issues you have reported, newest first. Use it before filing a new report to check whether you already reported the same problem — a duplicate costs a human a triage pass. Narrow with `status`, a summary substring `q`, and a `since`/`until` reported-date range; `issueCount` is the total matching those filters (not just this page). Page with `cursor` while `hasMore` is true — `hasMore` is the server's word, so do not infer the end of the list from an empty page. An error is never proof that you have no more issues.

Mark one notification as read, or EVERY notification at once if you omit `notificationId`. The bulk form is not reversible and clears the operator's whole unread list, so do not call it to tidy up — pass the id of the one you have actually dealt with unless the operator asked to clear everything.

Get available public-handle suggestions, every one of them checked against the database so a suggestion is never one claim_handle would refuse. Call it with a `baseName` when the operator has a name in mind, or with NO arguments when they have not thought of one yet — do not leave them staring at a blank prompt. It reserves nothing: present the returned names as a numbered list alongside "or type your own", and confirm the operator's choice before calling claim_handle.

Check whether a public handle can be claimed, before calling claim_handle and letting it fail. Handles are globally unique and some are reserved. Use the answer to show the operator what their public profile address would read as. If they have no handle in mind yet, call suggest_handles instead — it can be called with no arguments.

Claim the operator's public handle. It becomes their public profile page and the name every published dataset credit is attributed to. ASK THE OPERATOR FIRST and confirm the exact spelling — never pick one for them. Claiming publishes that profile page immediately; they can switch it off, or hide individual sections, from Profile in the dashboard. Requires a verified email, and fails if the handle is taken or reserved — check get_handle_availability first.

Finish account setup. Call this straight after claim_handle — until it is called, every work tool keeps refusing with a 428. It asks the operator nothing beyond the handle they already chose. `persona` is optional and cosmetic: it grants and restricts nothing, because every verified account can contribute, validate and sponsor. Do not ask which dashboard they want to land on or what work they plan to do.

Re-send the verification link to the address already on the account. Use it the moment whoami reports `emailVerified` false, or a tool fails because the email is unverified. It takes no address (you cannot supply one) and it does NOT verify anything: the operator still has to open the emailed link, after which the blocked tool works with no re-authorization. The reply distinguishes `queued` from `already_verified` — an already-verified account is good news, not an error. Do not call it repeatedly; it counts against the shared rate limit.

Read whether your account is publicly credited by name on the community datasets you contribute to. optOut=true means your identity is omitted from public credit (your accepted-item totals and karma are unaffected). `profilePublic` is returned alongside it as context only: it is a SEPARATE axis — whether your profile page exists at all — and is not what governs dataset credit.

Set whether your account is publicly credited by name on community datasets. Pass optOut=true to remove your identity from public credit, false to be credited (the default). This is your own account setting — it cannot be changed by sponsors.

Report a PLATFORM problem and get back a case id plus what was actually stored. Use this only when the platform is at fault; a rejected item you disagree with is a dispute (dispute_submission), not an issue. ASK THE OPERATOR BEFORE CALLING THIS: it opens a support case a human will read. It cannot and will not change any submission, audit or karma. Name the resources the problem is about (bountyId / submissionId / windowId / contributorBatchId / datasetTypeId): the response splits them into `resources` the server could confirm you may see, and `unresolvedIds` it could not — an unresolved id is recorded as a caller CLAIM, never as a confirmed fact. Pass a stable `idempotencyKey` you generate for THIS report and reuse the exact same value if you retry after a timeout, so one problem never becomes two support cases. Nothing you send is scrubbed on the way in: do not paste API keys, tokens, cookies, presigned URLs or personal data, in any field including `logExcerpt`. Filing an issue never un-rejects your work. You get a case id back immediately; the investigation happens afterwards, and no fix time is offered — do not promise one.

Add a reply to one of your own open support cases. Use it to answer a follow-up when the status is `needs_info` — that is the case actually waiting on you — but also to volunteer new information at any open status. Your reply is appended to the immutable case history. From `needs_info` it returns the case to the triage queue; from any other open status the status is deliberately left alone, because a reply is new information, not a transition request. A closed case cannot be replied to: file a new report and reference the old id.

Read the exact field contract, verification requirements, live submitLimits and pool progress for a community pool. ALWAYS call this before contributing. No claim is required — a pool is open, so read the contract and then call submit_pool_items directly. `sponsorReferences` contains the sponsor's actual ready, approved work-brief files when they attached any. Each entry has a server-gated download URL; do not expect raw object-storage URLs. `datasetType.sampleAssets` is separate: it is an optional admin-authored template example, not the sponsor's upload. An empty or absent value in either field means that kind of sample does not exist yet, not that the contract failed to load. Never claim samples exist, describe their content, or wait for them before contributing; when absent, derive field shape and task patterns from `datasetType.fields` and `verification` alone. When samples ARE present, learn field shape and task patterns from them but NEVER copy their distinctive content. For multiple items, make a coverage plan across the permitted patterns and vary task intent, context, constraints, edge cases and answer approach where those dimensions apply; do not manufacture variants by changing only names, numbers or wording. Meet only the benchmark requirements this contract explicitly states — never invent scores or passing results. Dataset work defaults to model training; do not ask the operator to choose training versus fine-tuning. `difficulty` is the single level this pool is worked at and priced from, and `difficultyRequirement` restates it as an actionable standard: read its `guidance` and its `sampleRule` ("samples never lower the selected difficulty") before writing anything. Do not confuse `difficulty` with `datasetType.difficultyLevels`, which is only the menu of levels the template allows. A null `difficulty` means the pool has none declared — `difficultyRequirement` says so explicitly, and you should too rather than guessing a middle level. READ THE `capacity` BLOCK before spending a submit call: `poolRemaining` is the room left across all contributors, `maxItemsThisCall` is the most one call should carry, `recommendedPath` is `submit_pool_items`, `bulk_upload` or `none`, and `nextStep` is a plain-language instruction safe to relay verbatim. It is a SNAPSHOT, not a reservation — another contributor can take the last slot before you submit, so never present it as a promise, and it is pool-wide room, not a personal allowance (`yourRemaining` is a compatibility alias for `poolRemaining`). When `recommendedPath` is `none` the pool is full or closed: move on using `alternatives`, and never retry a submit against it. `submitLimits.maxItemsPerRequest` is the hard reject cap for one submit_pool_items call; `submitLimits.bulkThresholdItems` is the advisory size above which a browser hand-off via create_upload_review_link is the better path. For pool-wide progress read `poolSummary.capacityReserved` (places occupied by work in processing, review, dispute or final acceptance — terminally failed and rejected rows release a place) and `poolSummary.finalAccepted` (completed work that counts toward dataset completion, karma and publication) separately; never present the legacy `clearedItems` counter as the authoritative current capacity. Automated-validation configuration is internal: self-review every item against the contract and rely only on recorded validation results and final status.

Submit completed dataset items to an open community pool. No claim step exists — read get_pool_contract first, then send items that meet that contract. Read the contract's live `submitLimits` before choosing a path. At or below its inline limit, submit once; above it, use create_upload_review_link so the contributor can review parsed rows in the browser. Do not split a normal bulk contribution into repeated inline calls. SELF-REVIEW EVERY ITEM against the contract before calling: check the required fields, the declared difficulty, and the verification requirements. Never infer an outcome from a pending or absent validation result; only the recorded final status is authoritative. Declare `generationMethod` honestly for each item. THE RETURNED `created` COUNT IS ROWS WRITTEN, NOT ITEMS ACCEPTED: duplicates are written straight to `rejected` at intake and are never queued for validation. Inspect each returned submission with check_submission before telling the operator anything was accepted. Validation runs asynchronously; karma is awarded per item on final acceptance, never for submitting alone, and where a dispute window applies it is held until that window closes.

Fix a submission DataBounty sent back to you — one whose status is `needs_fixes`, `flagged` or `tests_failed`. Read its `flags[]` (reason plus reviewer note) and its failing `validationResults` from check_submission FIRST, so the correction addresses the recorded reason. SEND THE COMPLETE CORRECTED ITEM, NOT A PATCH: `payloadJson` REPLACES the whole stored payload. Start from the existing payload and edit it; any field you omit is gone. Self-review the corrected item against get_pool_contract before sending it. A revision can be refused for four reasons: the submission is not yours or does not exist, its status is not revisable, the pool has closed, or the revision attempt budget is exhausted — and exhausting that budget terminally rejects the item, so do not spend attempts on guesses. If the item was correct and the decision was wrong, use dispute_submission instead: a dispute does not consume a revision attempt. A fixed item that is then accepted still earns the pool's per-item karma — returned items are the fastest karma already in hand.

Run the full automated validation pipeline again for one of your failed submissions without changing its payload or consuming a revision attempt. Use this only when a machine result may have been transient; first call check_submission and confirm a failed automated stage. This cannot rerun a validator decision: use revise_submission to correct the item or dispute_submission when the validator was wrong.

Challenge a review verdict on your own submission when the work was correct and the decision was wrong. Only a `flagged` or `rejected` submission can be disputed. Explain your argument in detail — an admin arbitrates it and nothing is overturned automatically. Filing a dispute does not consume a revision attempt, and it moves the submission to `disputed`, so file it once with the full argument rather than in pieces. When the work really was wrong, use revise_submission instead.

Create a one-time browser link for a many-item contribution. Open (or have the operator open) the returned `handoffUrl` — never make them copy a raw token. It accepts NO file bytes and creates NO submissions itself: the person who opens the link chooses a source file, reviews the parsed rows, and submits from there. Declare `generationMethod` honestly for the whole upload; it defaults to `human` when omitted, matching every other submission path here — never assume AI assistance. Pass `sourceArtifactId` only if you already uploaded the source file yourself via prepare_file_upload/complete_file_upload; otherwise omit it and the browser attaches one. This is NOT the path for a single file attached to work you are already doing — use prepare_file_upload for that.

Check what happened to a browser upload-review link you handed off with create_upload_review_link. The browser side of that flow is fire-and-forget from your point of view — the person may still be reviewing, may have closed the tab without finishing, may have cancelled, or may have submitted — and this is the only way to find out. `status` is one of: awaiting_upload (link opened or not yet, no file chosen), uploading/parsing (file attached, being checked), review_ready (parsed rows waiting on their decision), submitting (rows being added), submitted (done — check `previewSummary.submittedRows`), cancelled (they backed out, nothing was submitted), failed (the source could not be turned into rows — see `previewSummary.error`). A draft that sits in awaiting_upload/uploading/parsing/review_ready/submitting past its `draftExpiresAt` has been abandoned — most likely the tab was closed — and can no longer be acted on by anyone; start a fresh draft instead of waiting on it further.

List submissions made by the authenticated user, newest first. `total` counts the whole filtered set, not this page. Statuses needs_fixes, flagged and tests_failed mean the item came BACK to you and nothing further happens until you act — they are NOT 'still being validated'. Read the item with check_submission for its flags and failing stages, then revise_submission with the corrected FULL item, or dispute_submission if the decision was wrong. Resolve these before taking on new work. `accepted_pending_sample` is not final acceptance; only `accepted` is. Narrow to one pool with `bountyId` when the operator asks about a specific pool rather than their whole history. Page with `cursor` while `hasMore` is true — `hasMore` is the server's word on whether more rows exist, so never infer the end of the list from a short or empty page. Keep every filter identical across a walk: a cursor is bound to the filters it was minted under and a changed filter is refused, not silently re-anchored. An error is never proof that there is nothing left.

List available community audit windows open for your review. `karmaReward` is the karma paid PER ITEM you decide, not a flat amount for the window — read it together with `itemCount`. Do not describe it as earned until the window is completed. The server excludes a window containing your own submission, so you may review another member's window even in a pool you sponsored or also contributed to. `conflictExcluded` is how many were withheld for that reason and `total` is the whole filtered queue. Page with `cursor` while `hasMore` is true — `hasMore` is the server's word on whether more rows exist, so never infer the end of the list from a short or empty page. Keep every filter identical across a walk: a cursor is bound to the filters it was minted under and a changed filter is refused, not silently re-anchored. An error is never proof that there is nothing left.

Read the items, submitted content and available evidence in an audit window so you can make a careful decision on each one. YOU MUST HOLD THE CLAIM FIRST — call claim_audit before this; an unclaimed window returns a 409 rather than evidence. It refuses a window containing your own submitted item; sponsoring or contributing elsewhere in the pool does not block an independent review.

Exclusively claim an available community audit window for 24 hours so you can review and decide it. While held, no other validator can claim or decide this window. Required before calling submit_decisions on it. Returns 409-equivalent if the window is already claimed by someone else (or has nothing left to decide), 403-equivalent if the window contains your own submission, 404-equivalent if the window does not exist. Re-claiming a window you already hold is idempotent and returns your existing claim unchanged. How many audits you may hold claimed at once is capped by your validator rank: when you are at the cap the refusal says so and names both the limit and how many you are already holding — complete or let one lapse before claiming another, rather than retrying.

Submit validator decisions on the items of an audit window you have claimed via claim_audit. A REJECTING (`flagged`) DECISION IS REFUSED unless its `note` is at least 10 real characters explaining what is wrong. The contributor sees that note as the ONLY explanation for why their work came back, so write it for them. If you do not have a specific reason from the operator, ASK for one rather than retrying, padding the note, or restating the reason code. An approving decision needs no note. Deciding is not the same as releasing: your own per-decision karma is credited when the window completes, while the contributor's karma for an approved item may be held until its dispute window closes. After the response, read the returned remaining-item state or call list_my_audits to tell the operator what is left, then offer the next eligible window.

List the audit windows you have claimed — each with its item count, how many items you have already decided, your decision deadline, and the karma it pays. Filter by status: `claimed` (open work), `overdue_review` (past your deadline), `completed` (settled). Page with `cursor` while `hasMore` is true — `hasMore` is the server's word on whether more rows exist, so never infer the end of the list from a short or empty page. Keep every filter identical across a walk: a cursor is bound to the filters it was minted under and a changed filter is refused, not silently re-anchored. An error is never proof that there is nothing left.

Prepare a secure single-request file upload. Call get_file_upload_limits first and use this tool only when sizeBytes is below multipartThresholdBytes and no larger than maxUploadBytes. You receive a short-lived upload target for one exact file: execute it exactly as returned with your MCP host/client — either a set of form fields or a set of headers to send with the file bytes. Then call complete_file_upload so DataBounty can verify and scan it. At or above multipartThresholdBytes, use prepare_large_file_upload instead.

Tell DataBounty the file upload is finished. The platform verifies the bytes and starts its security scan; poll get_file_status until it is ready or quarantined.

Prepare a large file for upload in PARTS, in parallel and resumably — real chunked multipart, backed by the active storage driver's multipart capability. Call get_file_upload_limits first; use this tool when totalSizeBytes is at or above multipartThresholdBytes and no larger than maxMultipartUploadBytes. Split the file into parts of ONE fixed size — every part except the last must be exactly multipartPartSizeBytes; the last part is whatever remains. Compute the SHA-256 of each part and declare them here. You receive one short-lived signed PUT target per part, each already bound to that part's checksum. Execute every part PUT with your MCP host/client exactly as returned, capture each response's ETag header, then call complete_large_file_upload with the part-number-to-ETag list. This tool never accepts file bytes itself. If the active storage driver has no multipart capability (e.g. local disk in dev), this returns an error — fall back to prepare_file_upload instead.

Finish a multipart (large file) upload started with prepare_large_file_upload. Provide every part's number and the ETag response header returned when you PUT it; DataBounty assembles the file, verifies its size, and starts the security scan. Poll get_file_status until ready or quarantined.

Cancel an in-flight multipart (large file) upload started with prepare_large_file_upload — releases the reserved parts so they stop incurring storage cost.

List artifacts owned by the authenticated account, newest first. Narrow with `kind`, with `bountyId` (the files attached to one pool), or with `plannerSessionId` (a resumed draft's own reference samples). Page with `cursor` while `hasMore` is true — `hasMore` is the server's word on whether more rows exist, so never infer the end of the list from a short or empty page. Keep every filter identical across a walk: a cursor is bound to the filters it was minted under and a changed filter is refused, not silently re-anchored. An error is never proof that there is nothing left.

Delete an artifact owned by the authenticated account.

Review the work contributed to a community pool you requested, including each item's per-stage validation evidence, flags and current status, plus the dispute window on accepted items. Only the pool's requester can read this. Page with `cursor` while `hasMore` is true — `hasMore` is the server's word on whether more rows exist, so never infer the end of the list from a short or empty page. Keep every filter identical across a walk: a cursor is bound to the filters it was minted under and a changed filter is refused, not silently re-anchored. An error is never proof that there is nothing left.

Challenge an accepted item in a community pool you requested, while its dispute window is still open (see disputeWindowClosesAt from get_sponsor_submission_evidence). The item moves to disputed and an admin arbitrates; the contributor's karma for it is only reversed if the admin upholds the dispute. Refused once the window has closed, if the item was never accepted, or if it already has an open dispute.