> ## 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. # Review, consensus, and adjudication > Understand the intended decision model for independent reviews, agreement rules, conflicts, and accountable resolution. **Status: Planned — not available yet.** This page is a target contract: a precise description of how reviews and disagreements are intended to work. No review-routing or decision system is available today. ## Review A review is an assessment of a proposed change against a known instruction, recorded with the reviewer's identity. The intended record should distinguish outcomes such as accept, return for correction, abstain, or escalate, together with any required reason. A review is evidence. It does not by itself define the overall decision when a policy requires several reviews or another approval. **Status: Planned — not available yet, and the exact outcome names are an open decision.** The names used on this page — accept, return for correction, abstain, escalate — describe what a reviewer intends. Early implementation work records a shorter and differently shaped set: accept, correct, and reject. Those two vocabularies do not line up, and this page does not pretend they do. Which set survives, and whether “reject” means “return for correction” or something stronger, is unsettled. The last column concerns the total a rule counts against. If a rule says “two of three reviewers must accept”, it must also say which three: which reviews count toward the required total, and which are set aside. Deciding that is one of the hardest parts of writing the rule. | Reviewer outcome | Reason required? | What happens next | Effect on the required total | | --------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Accept | Usually not, unless policy asks for one. | The outcome is recorded and counts as acceptance evidence under the rule. | Counts toward the required total, and counts as agreement. | | Return for correction | Yes. A correction without a reason is guesswork for the author. | The proposal goes back to its author with the reason attached. | Counts toward the required total, but not as agreement. It is not acceptance. | | Abstain | Yes, so a later reader knows why judgement was withheld. | The reviewer is recorded as having withheld judgement. | Open. The written rule must say whether an abstention lowers the required total or counts against agreement — the two choices give different answers to the same reviews. | | Escalate | Yes. The escalation reason is what the decision-maker reads first. | The item routes to an authorized decision-maker for adjudication. | Open. The rule must say whether an escalated item still counts as awaiting agreement or has left the agreement process entirely. | The two rows marked Open are not oversights. They are the questions a written policy has to answer before any of this can be implemented, and a system that answers them silently is worse than one that refuses to guess. The states an item can be in — including outcomes that were never recorded at all — are set out separately below. ## Consensus **Consensus** means that the required level of agreement has been reached under a written rule. Examples include unanimous agreement, a minimum threshold, or a required specialist review. The rule must say which reviews count, how abstentions behave, and what happens when the threshold is not met. The planned decision rule avoids silently converting “two of three tasks completed” into acceptance. Missing and ineligible outcomes remain visible. **Status: Planned — not available yet.** No system applies any of these rules today. The comparison is here so you can choose one deliberately for your own policy. | Rule | What it requires | How it treats a missing outcome | Its characteristic failure | | ------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Unanimous | Every eligible review accepts. | Nothing is decided until every required review exists. | Stalls. One unavailable reviewer holds the item indefinitely unless escalation is defined. | | Threshold | At least a stated number of eligible reviews accept. | The rule must say whether the missing outcome still counts in the total. | Quietly becomes majority voting, and a threshold met by two accepts out of two completed reviews looks the same as two out of three. | | Required specialist | A named qualification must be among the accepting reviews. | An absent specialist blocks the decision regardless of how many others accepted. | Reads as satisfied when a generalist reviewer's acceptance is miscounted as the specialist's. | ### Why “two of three completed” is not “two of three agreement” Three reviewers are assigned to one proposal. Two of them finish; the third records nothing. Of the two who finished, one accepts and one returns the work for correction. A progress view honestly reports two of three tasks completed. An agreement rule looking at the same item sees one acceptance, one return, and one missing outcome — one accept out of three, not two out of three. Under a threshold rule requiring two accepts, this proposal has not reached agreement, and it is not close: there is an unresolved disagreement and an absent reviewer. Reporting the completion figure as if it were the agreement figure is the single most consequential mistake in this area, because it converts a contested item into an accepted one without anyone deciding to do so. ## Adjudication **Adjudication** is a final, accountable decision about a contested item. The decision-maker should see the proposal, competing reviews, instructions, and change history. The decision should record a reason and make the next step clear. Adjudication is not an automatic average of shapes or scores. It is a decision made by an authorized person under a known rule. The evidence a reviewer needs in front of them is listed in [What a reviewer should see](/guides/annotate-and-review#what-a-reviewer-should-see). ## Conflicting edits When two proposals change overlapping content, a future implementation needs to detect the relevant conflict and route it according to policy. The correct unit of conflict, comparison method, and merge behavior require runnable product tests. This documentation does not claim automatic voxel-level conflict handling is available.

Planned decisions

How planned review outcomes differ

| State | Meaning under a written rule | | ----------- | ------------------------------------------------------------------------------------------- | | Accepted | Eligible acceptance evidence; it counts only under the written agreement rule. | | Returned | Sent back for correction with any reason required by policy; it is not acceptance. | | Abstained | Remains visible; the written rule defines whether it counts in the total. | | Missing | No outcome was recorded; completion or elapsed time cannot replace it. | | Ineligible | Recorded but excluded from eligible agreement under the written rule. | | Contested | Genuine disagreement remains unresolved and routes to an authorized decision-maker. | | Adjudicated | An authorized final decision records the result and reason; it is not an automatic average. |

Planned meanings for review outcomes. No review-routing or decision system is available today, and release approval remains separate where policy requires it.

## Example policy questions * Must reviewers be independent of the author? * Does a machine-authored proposal always require a human reviewer? * Which domain qualifications make a review eligible? * How many outcomes are required? * Can a reviewer abstain, and does that change how many reviews are required for a decision? * Which disagreements require adjudication? * Who may overturn or withdraw a decision? * How does a correction affect a previously released dataset? Use the worksheet below to answer them for one workflow. **Status: Planned — not available yet** — nothing here is configured in a product; the third column describes what happens in a team's process when the question is left open, which is the reason to answer it now. | Question | Your rule | Consequence if left unspecified | | --------------------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------- | | Must reviewers be independent of the author? | | Authors end up reviewing their own work, and the review record stops being evidence of anything. | | Does a machine-authored proposal always require a human reviewer? | | Model output reaches a release without a person ever having accepted responsibility for it. | | Which domain qualifications make a review eligible? | | Every review counts equally, and a specialist judgement is diluted by reviewers who lack the background. | | How many outcomes are required? | | Whoever reports first defines the result, and the number varies from item to item. | | Can a reviewer abstain, and does that change how many reviews are required? | | Abstentions are counted inconsistently, so the same reviews produce different answers on different days. | | Which disagreements require adjudication? | | Disagreement is resolved by whoever is most persistent rather than by whoever is authorized. | | Who may overturn or withdraw a decision? | | A decision can be reversed without a record, and the history no longer explains the current state. | | How does a correction affect a previously released dataset? | | Consumers keep training on data known to be wrong, because no one is obliged to tell them it changed. | ## Common mistakes and limits * More reviewers do not guarantee a better policy. * Consensus is not majority voting unless the policy says so. * A confidence score is not a review decision. * Automatically merging overlapping labels can erase important disagreement. * Synthetic persona evaluations of these docs are not domain-expert validation of the product model. ## Next step Write the review and escalation rule for one representative structure, then use it while reading the guide to [releasing a dataset](/guides/dataset-release).
OutcomeDescribe a review policy without hiding disagreement or confusing task completion with acceptance.
AvailabilityPlanned — not available yet
AudienceReviewers, Domain experts, Program managers, Data scientists
PrerequisitesA written review instruction or quality rule; Named owners for escalation and final decisions
Last verified2026-08-23