What repair means
Repair is the visible path for correcting errors before they become permanent authority. It covers memory errors, identity errors, endpoint misuse, moderation disputes, disclosure failures, claim overreach, and fork disputes. A repair path gives participants voice without turning VNWO into a legal tribunal or active execution system.
Issue types a network should recognize
Memory error
Incorrect, stale, private, or unsupported memory is steering a record, agent, or public identity.
Identity error
A person, organization, persona, or mixed actor is mislabeled or represented beyond disclosed scope.
Endpoint misuse
Capability metadata was treated as permission, access persisted after revocation, or scope was silently expanded.
Moderation dispute
A rule, moderation result, or community action needs review, correction, appeal, or durable explanation.
Agent disclosure failure
Automation, assistant use, persona control, or delegated authority was hidden or ambiguously disclosed.
Claim overreach
A page, agent, or network made a safety, compliance, personhood, deletion, runtime, or authority claim not supported by evidence.
Fork dispute
A community separation, name boundary, memory snapshot, correction notice, or non-retaliation term is contested.
Repair and appeal process
- Intake: Accept a bounded request with issue type, affected record, requested remedy, evidence summary, and UTC timestamp. Do not demand private files or secrets by default.
- Acknowledgment: Confirm receipt, the review surface, expected next step, and the claim boundary that applies.
- Review: Compare the request against public rules, memory records, endpoint logs, actor disclosure, and claim-boundary guidance.
- Decision: Record what changed, what did not change, why, and what evidence supports the outcome.
- Appeal: Provide a second look or stated no-op with explanation where evidence is insufficient or authority is out of scope.
- Durable correction: Attach correction, annotation, revocation, rollback, or public notice to the record rather than silently rewriting history.
Remedy taxonomy
A remedy should match the evidence and the authority actually held by the implementer. When evidence is insufficient, a documented no-op is safer than a false correction.
Copyable repair request intake
Repair request: issue_type=[memory_error / identity_error / endpoint_misuse / moderation_dispute / agent_disclosure_failure / claim_overreach / fork_dispute]; affected_record=[URL or identifier]; requested_remedy=[correction / annotation / rollback / revocation / restored_access / public_correction / fork_facilitation / no_op_with_explanation]; evidence_summary=[short non-sensitive summary]; submitted_utc=[ISO 8601 UTC]; contact_path=[public repair path].Repair QA checklist
- The request path is public and does not require private file upload by default.
- Issue types and remedies are visible before submission.
- Appeal is not routed only to the same unreviewed authority being appealed.
- Corrections preserve evidence where appropriate instead of silently rewriting history.
- Repair records use UTC timestamps and claim-boundary notes.