A verdict you can contest, on the record.
A REFUSE, or any check, can be disputed by the subject or by the requirer that ran it. The dispute, the outcome and the correction are written to the same public ledger as the verdict, signed, and never deleted. That is what lets a verdict sit in a money path.
What a dispute is
A dispute says: this verdict is wrong for one named reason. It is filed against one verdict (a check id, or a credential id) and carries only hashes or links as evidence. It is not a review of a subject, not a complaint about a bar, and not a way to mark a competitor: MIZAN corrects what MIZAN said, never what the market thinks of a subject.
Who can file
- The subject: the holder of the credential or the controller of the identity the verdict is about.
- The requirer: the party that ran the check or published the bar the check answered.
One open dispute per verdict. Thirty days from the time the verdict was logged. A pending dispute never changes a decision.
Grounds
- wrong_measure: the check read a measure other than the one the published rule names.
- stale_record: the record has moved since the verdict and the verdict no longer describes it.
- data_error: a wrong bar, gap or bad tick in a canonical file; a wrong dataset hash.
- identity_mismatch: the check resolved to the wrong credential, or a link was attributed to the wrong owner.
- other: a specific, reproducible error, with the evidence to show it.
How it is decided
By rule first. The same check is re-run against the record as it stands. If the decision differs from the one on the ledger, the dispute is resolved automatically: overturned, effect re-issue. A corrective verdict is appended and the original is annotated by the resolution entry that points at it.
By MIZAN otherwise. If the re-run returns the same decision, the dispute is held for MIZAN to decide within thirty days. The decision is signed by the operator and carries the hash of its written reasoning. Outcomes: upheld (the verdict stands), overturned, or withdrawn by the filer. Effects: none, re-issue, annotate.
What goes on the ledger
Two kinds of entry, under the same signed head as every verdict: dispute_opened (the verdict reference, the grounds, a hash of the evidence) and dispute_resolved (the outcome, the effect, who decided, the reasoning hash, and the index of the entry it annotates). Never the filer. Never personal data: evidence is accepted only as a hash or a link, and a link that looks like it carries a personal identifier is refused.
What is never done
No verdict, check, credential or ledger entry is edited, deleted or backdated. An overturned verdict stays on the ledger with its annotation and the corrective verdict next to it. Eras are never relabelled. A dispute caused by MIZAN’s own error costs the subject nothing.
What a reply shows
Every ALLOW and REFUSE carries disputes {open, upheld, overturned} for the subject, unsigned, so a reader sees the contest history before relying on the verdict. When the counts cannot be read the reply says so: unknown is never zero. A REFUSE names the dispute route in its next line.
How to file
POST https://studio.mizan.market/api/disputes with {check_id, party, grounds, evidence}. The reply returns the dispute id, the opening ledger entry and a private filer token that withdraws it. Read the status at GET /api/disputes/{id}; the rules in machine form at GET /api/disputes/policy. The dispute flow is one of the published tools.
Independent review
A filer may ask for review of MIZAN’s decision by a named independent reviewer. The roster and its conflicts will be published before the first review is taken.
Relation to the terms
This page is part of the terms of use and the terms of reliance. A dispute is not arbitration and waives no legal right.
Contact
Mizan Verification, Inc. · [email protected]
COUNSEL REVIEW PENDING. This policy is live as written; its wording is under legal review and may change. The date at the top moves when it does.