Skip to main content
Limited design-partner access Status: Limited editor; complete workflow planned. A limited design-partner queue and annotation editor exist. The complete annotation, submission, review, adjudication, and release experience described on this page is a target contract, not a public product.

​
What you can do today

Inside an agreed design-partner workspace, an annotator can open held work, draw or correct labels, recover drafts, and commit changes. Task submission, reviewer, adjudicator, and release workflows are not available, and there is no public sample workspace. Before an evaluation, prepare one instruction, one representative task, and the rule your team uses to return work for correction or escalate it for a final decision.

​
Your intended outcome

An annotator should be able to open an assigned item, understand what must be labelled, do the work, and submit it without learning version-control vocabulary. A reviewer should be able to see what changed, why it changed, and what decision is required. Internal and external annotators need the same task clarity. External contributors also need a visibly limited scope: they should not have to guess which project, data, or history they are permitted to see.

​
Intended task flow

  1. Open an assignment that names the source study, target structure, instructions, and deadline or timing.
  2. Confirm that the source images and label taxonomy match the task.
  3. Create or correct the requested label.
  4. Record a concise reason when the work departs from the instruction or model proposal.
  5. Submit the change for review.
  6. Receive an accepted, returned, or escalated result with a clear next action.
The limited editor covers only part of this flow. The full sequence is a planned description, not an available product walkthrough. There is no public account or sample workspace to open today. Status: Partial design-partner editor; workflow planned. The current queue and editor can open held work, draw or correct labels, recover drafts, and commit changes. A reviewer can accept, correct, or reject a held review task in the editor; consensus and adjudication remain planned. The table below therefore mixes the limited steps that exist with the complete target flow that remains planned. The second column is what you would do; the third is what the system would keep afterwards, which is what makes the work reviewable later. Step 6 is where the flow stops being a line. Accepted work continues toward a release. Returned work comes back to you at step 3 with a reason you can act on. An escalated item leaves your hands entirely and goes to an authorized decision-maker — you are not expected to resolve a disagreement between reviewers, and the record should make clear that you did not.

​
What a reviewer should see

A review should separate the label change from the decision about that change. The intended evidence includes the relevant source view, the previous and proposed label, who or what authored it, applicable instructions, and prior review outcomes. Domain experts should not need to inspect technical logs. They do need a clear record of where a change came from, who or what made it, and which earlier version it changed. This record is called provenance. Status: Partial design-partner reviewer surface; the full evidence view is planned. A limited reviewer surface exists in the editor: a reviewer can open a held review task, see the task context, and record accept, correct, or reject, with a corrected annotation shown as corrected rather than accepted. It does not yet show every row below. Use the checklist as a list of things to ask for: a review interface that cannot show one of these rows is asking you to sign off on something you cannot see.

​
Consensus and escalation

When several independent reviews are required, the intended workflow records each outcome before deciding whether the required level of agreement has been reached. Disagreement is not silently averaged away. A contested result should go to an authorized person who can see the competing evidence and record a reasoned final decision. That step is called adjudication. Read Review, consensus, and adjudication for the planned decision model.

​
Common mistakes and limits

  • Do not assume an annotator can change permissions, taxonomies, or release state.
  • Do not use a shared account for an external contributor; the history should identify who performed each action.
  • A model suggestion is not an approval. It should remain identifiable as machine-authored work.
  • A completed task does not automatically mean the dataset is released.
  • This documentation does not prove keyboard shortcuts, viewer performance, medical-device suitability, or production access.

​
Next step

If this task model resembles your work, read Design-partner onboarding and bring one representative task, its instruction, and its current review/escalation rules to the first conversation.
OutcomeExplain your intended task, evidence, and escalation path during a design-partner evaluation.
AvailabilityLimited design-partner access
AudienceInternal non-technical annotators, External non-technical annotators, Reviewers, Domain experts
PrerequisitesKnow the structure or finding your team wants labelled; No API or storage knowledge required
Last verified2026-08-23