> ## Documentation Index > Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes. > A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it. > Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct. > Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release. # Annotate and review > Understand the intended annotation, review, and domain-expert experience without needing engineering knowledge. **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 | What the annotator does | What the system records | | ---- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | 1 | Opens an assignment naming the source study, target structure, instructions, and timing. | That this assignment was opened, by whom, and which instruction version applied. | | 2 | Confirms the source images and label names match the task before starting. | The source references and the taxonomy version the work was done against. | | 3 | Creates or corrects the requested label. | The proposed label and the earlier state it changed. | | 4 | Writes a short reason when the work departs from the instruction or a model proposal. | The reason, attached to the change rather than kept in a separate message. | | 5 | Submits the change for review. | The submission, its author, and the point at which authorship ends and assessment begins. | | 6 | Receives one of three results: accepted, returned for correction, or escalated for a final decision. | Which of the three occurred, who decided it, and the reason where the outcome requires one. | 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. | A reviewer should be able to see | Why it matters to the decision | | --------------------------------- | ----------------------------------------------------------------------------------------------- | | The relevant source view | Without the underlying images, you are assessing a shape rather than an interpretation of data. | | The previous label | Says what the change is departing from, which is often the real subject of the review. | | The proposed label | The change itself, shown against the previous state rather than on its own. | | Who or what authored it | A person and a model are not equally accountable, and machine-authored work stays identifiable. | | The applicable instructions | A review assesses work against a written instruction; without it you are substituting your own. | | Prior review outcomes | Tells you whether you are the first reviewer or joining an existing disagreement. | | The reason attached to the change | Explains a departure from the instruction that would otherwise look like a mistake. | ## 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](/concepts/review-consensus-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](/guides/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