Disputes

MIR is a neutral registry. We record what happened and when — we don't judge who is right. Disputes are a first-class mechanism for adding context, challenging claims, and preserving your right to respond. Nothing is silently deleted. Everything leaves a trail.

How disputes work on MIR

There are three distinct dispute mechanisms on MIR, each designed for a different situation:

1. Event Disputes

Users challenge negative events recorded against them by partner platforms. The event stays, but is flagged as disputed.

2. Assertion Disputes

Issuers cryptographically challenge another issuer's assertion about a media artifact. Public and permanent.

3. Issuer Appeals

Issuers whose accounts have been suspended or restricted can formally appeal the decision with evidence.

Core principle: MIR never silently removes data. Disputed events are annotated, not deleted. Disputed assertions are publicly visible. The trail of what happened, and when, is always preserved.

Event Disputes (Users)

When a partner platform records a negative event against you — a chargeback, policy violation, suspension, or other negative signal — you have the right to dispute it. Disputing an event does not delete it. It flags it as contested and attaches your reason.

Who can file

Any authenticated user, for events recorded against their own account.

What can be disputed

Only negative events (those with a negative weight). Positive events like completed transactions or verified reviews cannot be disputed — there's no reason to contest something in your favor.

How to dispute an event

  1. Sign in to your account
  2. Navigate to your event history
  3. Find the negative event you want to challenge
  4. Click "Dispute" and optionally provide a reason (up to 500 characters)

What happens next

Event recorded → User disputes → Event flagged as disputed

Important: Disputing an event does not erase it. MIR is a transparency layer. The dispute annotation gives you a voice — consuming platforms decide what weight to give it.

Scenarios

User

Wrongful chargeback flag

A partner records a chargeback event against you, but the chargeback was filed by a fraudster who stole your card — not by you. You dispute the event with the reason: "Unauthorized transaction. Fraud case resolved by bank. Reference #12345." Platforms querying your history see the dispute and can weigh it accordingly.

User

Policy violation you disagree with

A partner records a policy violation for content they deemed inappropriate. You believe the content complied with their terms. You dispute the event with your explanation. The event stays, your side of the story is attached, and any future platform considering it can see both the event and your response.

Edge case

Disputing then undisputing

You dispute an event, then realize the partner was correct. You can remove the dispute flag at any time via the "Undispute" action. The event returns to its original undisputed state. The dispute history is not permanently recorded — the flag is a toggle, not a log entry.

Edge case

Trying to dispute a positive event

You cannot dispute events with a positive or zero weight. MIR only allows disputes on negative events because there is no reasonable basis for contesting something that benefits your reputation.

Assertion Disputes (Issuers)

Media assertions are cryptographically signed statements about artifacts — like "we published this image" or "this video is not from us." When an issuer disagrees with an existing assertion on an artifact, they can file a DISPUTE assertion.

Unlike event disputes (which are private annotations), assertion disputes are public and permanent. Anyone looking up the artifact sees the dispute alongside all other assertions.

Who can file

Any registered issuer with an active signing key and a valid subscription (or founder status). The dispute is cryptographically signed like any other assertion.

How it works

  1. Issuer identifies an artifact hash with assertions they want to challenge
  2. Issuer creates a new assertion with type: "DISPUTE" against the same artifact hash
  3. The signed payload includes the artifact hash, type, issuer ID, and timestamp
  4. Optional scope and context fields explain what is being disputed and why (up to 500 characters)

What happens next

Assertion exists → Issuer files DISPUTE → Conflict visible publicly

MIR does not adjudicate. We display both sides. Anyone querying the artifact sees all assertions — including disputes — and decides for themselves which issuers to trust.

What triggers a conflict

MIR automatically flags an artifact as "conflicting" when any of these conditions are true:

Scenarios

Issuer

Deepfake denial

A news organization discovers a manipulated video circulating with false attribution. An unknown issuer has asserted ISSUED_BY on the deepfake's hash. The real news organization files a DISPUTE assertion with context: "This is a manipulated version of our original reporting. The authentic version has hash abc123..." Anyone looking up the artifact sees both claims and can evaluate the issuers' credibility.

Issuer

Misattribution correction

Issuer A asserts ISSUED_BY on an image. Issuer B, the actual creator, files a DISPUTE with scope "authorship" and context explaining that Issuer A licensed the image but is not the creator. Both assertions remain visible. Issuer A can respond by filing a ROLE_SCOPE assertion clarifying their role as distributor rather than creator, and optionally revoking their ISSUED_BY.

Issuer

Superseding instead of disputing

Sometimes an issuer realizes their own previous assertion was wrong — perhaps they asserted the wrong type or included incorrect context. Instead of filing a dispute against themselves, they use the supersede mechanism: POST /assertions/:id/supersede creates a new corrected assertion and links it to the old one. The old assertion is marked as superseded, the new one replaces it.

Edge case

Cross-assertion alert vs. dispute

When any issuer creates any assertion type on an artifact that already has assertions from a different issuer, MIR sends an admin alert. This is not the same as a dispute — it's an informational notice. A legitimate scenario (e.g., two news agencies both asserting ISSUED_BY on a joint production) triggers the same alert. Only an explicit DISPUTE assertion triggers the conflict flag.

Edge case

Visually similar artifacts with different hashes

A manipulated version of an image has a different SHA-256 hash than the original. If both have assertions with perceptual hashes, MIR's visual match system will detect the similarity and surface related artifacts in lookup results. This cross-referencing helps connect deepfakes to originals even when the cryptographic hashes differ. It does not automatically create a dispute — that is left to the issuers.

Edge case

Dispute on an artifact with no other assertions

An issuer can file a DISPUTE assertion on an artifact that has no other assertions. This is valid — it publicly records that the issuer contests the artifact's authenticity or provenance without requiring another issuer to have asserted first. The conflict flag will still be set.

Issuer Appeals (Suspension & Restriction)

If an issuer's account is suspended or restricted by MIR administration — for example, due to policy violations, abuse, or compromised keys — the issuer has the right to formally appeal the decision.

Who can file

The issuer whose account has been suspended or restricted. You must be authenticated via your partner API key or session. Appeals can only be filed when your account status is SUSPENDED or RESTRICTED.

How to appeal

  1. Sign in to the Issuer Portal
  2. Your dashboard will show your suspension or restriction status and the reason
  3. File a dispute providing:
    • Contact name (min 2 characters)
    • Contact email (valid email)
    • Statement (min 50 characters) — explain why the action was wrong or why it should be reversed
    • Evidence (optional) — links, documentation, or context supporting your case

Appeal lifecycle

PENDING → REVIEWING → OVERTURNED or UPHELD

Constraints

While your appeal is pending, your account remains in its suspended/restricted state. You cannot create assertions until the appeal is resolved (overturned) or you are reinstated through other means.

Scenarios

Issuer

Compromised key, not issuer abuse

An issuer's signing key was compromised, and a bad actor used it to create fraudulent assertions. MIR suspends the issuer. The issuer files an appeal explaining that the key was compromised, provides evidence of the security incident, and asks to be reinstated with a new key. If the appeal is overturned, the issuer revokes the compromised key, registers a new one, and resumes operations.

Issuer

Policy misunderstanding

An issuer is restricted for creating assertions that appear to violate MIR's neutrality principle (e.g., using assertions as a marketing tool rather than provenance claims). The issuer files an appeal explaining their intended use case and providing context that distinguishes their use from the violation. The admin reviews, agrees the restriction was overly broad, and overturns it with a resolution note clarifying the policy boundary.

Admin

Appeal upheld — genuine violation

An issuer is suspended for systematic creation of false ISSUED_BY assertions on content they didn't create. The issuer appeals claiming the content was licensed. After investigation, the admin finds no evidence of licensing and upholds the suspension. The resolution note documents the investigation and finding. The issuer's appeal is permanently marked as UPHELD.

Edge case

Re-suspension after overturn

An issuer's appeal is overturned and their account is restored. Later, they violate policy again and are suspended for a new reason. This creates a new IssuerStatusChange record, and the issuer can file a fresh appeal against this new action. The previous overturn does not protect against future enforcement.

How disputes are resolved

Resolution depends on the dispute type.

Event disputes: platforms decide

MIR does not resolve event disputes. The dispute flag is an annotation visible to all consuming platforms. Each platform independently decides how to weigh a disputed event. Some may ignore disputes entirely. Others may treat any disputed event as neutral. MIR's role is to ensure you can tell your side of the story.

Assertion disputes: the public decides

MIR does not determine which issuer is telling the truth. When conflicting assertions exist, the lookup page displays all of them with a conflict warning. Anyone verifying an artifact evaluates the issuers' credibility, verification status, and domain reputation to form their own judgment. Over time, issuers may revoke their own assertions or file superseding corrections as situations are resolved externally.

Issuer appeals: admin decides

Issuer suspension and restriction appeals are the only disputes that MIR actively adjudicates. An administrator reviews the appeal, the original enforcement reason, and any evidence provided. The outcome is either UPHELD (action stands) or OVERTURNED (account restored). Both outcomes include a written resolution.

MIR's default is neutrality. We don't edit history, suppress information, or pick sides. Disputes add transparency, they don't replace it.

Summary

Type Who files What happens Who resolves Reversible
Event dispute User Negative event flagged as disputed Consuming platforms Yes (undispute)
Assertion dispute Issuer DISPUTE assertion created, conflict flagged The public / issuers Yes (revoke)
Issuer appeal Issuer Formal appeal of suspension/restriction MIR admin If overturned

Edge cases and frequently asked questions

Can I dispute an event from a partner that no longer exists?

Yes. The dispute is recorded against the event itself, not the partner. Even if the partner's account is disabled, the event remains in your history and you can dispute it. However, since the partner can no longer update or remove the event, the dispute flag becomes the only additional context available.

What if two issuers both legitimately created the same content?

This is not a conflict — it's collaboration. Both can file ISSUED_BY assertions on the same artifact hash. MIR does not treat multiple ISSUED_BY assertions from different issuers as a conflict. The conflict flag only triggers when contradictory types exist (e.g., ISSUED_BY vs NOT_ISSUED_BY) or when an explicit DISPUTE is filed.

Can an issuer dispute their own assertion?

Technically yes, but the correct mechanism is revocation (if the assertion was wrong) or supersession (if a correction is needed). Self-disputes are valid but unusual and would appear strange in the public record.

What if I run out of characters in my dispute reason?

Event dispute reasons are capped at 500 characters. Assertion dispute context is also 500 characters. If you need more space, keep the on-record text concise and reference an external document (e.g., "Full evidence at [URL]"). For issuer appeals, the statement field accepts longer text, and you can include evidence links.

Can MIR override a dispute?

MIR does not modify or remove event disputes or assertion disputes. These are controlled entirely by the user or issuer who filed them. MIR administrators can only resolve issuer appeals (suspension/restriction disputes). MIR will never edit the text of a dispute or remove it without the filer's consent.

What happens to disputes if I delete my account?

If you delete your MIR account, your event disputes are removed along with all your data. Assertion disputes (filed by issuers) persist because they are tied to the issuer's account, not yours. Issuers cannot delete their assertions by deleting their account — assertions are permanent records.

Is there a time limit for filing disputes?

No. Users can dispute events at any time, regardless of how old they are. Issuers can file assertion disputes at any time. Issuer appeals must be filed while the account is still in suspended or restricted state.

Need help with a dispute?

If you need assistance or believe something about your MIR record is wrong and the self-service dispute mechanisms aren't sufficient:

For questions about how disputes work, see our FAQ or reach out via contact.