Uhpenry Trust & Reports System

Uhpenry is a developer marketplace where trust is built deliberately. The Trust & Reports System ensures that disputes are handled fairly, harmful behavior is stopped quickly, and an auditable record of events is always preserved.

Core Principles

Every action on Uhpenry ties back to a Public ID, an immutable identifier assigned to projects, SnapGates, SnapCharges, and more. Because these IDs never change, evidence like screenshots or commit hashes always point to the exact object in question. This gives reports precision and creates a permanent, reliable audit trail.

The system is also evidence-first. Reports must include artifacts such as screenshots, URLs, or logs. This prevents vague or abusive reports and ensures issues can be independently verified.

How Reporting Works

When a user reports a Public ID:

• The object is marked as “reported,” with a visible status banner.
• The owner is notified immediately.
• Both reporter and owner gain access to a private dispute channel to communicate and exchange fixes.

This workflow makes disputes transparent, while ensuring that both sides can respond quickly.

Grace Period & Hiding Rules

Uhpenry balances safety with developer empathy:

• A 4-hour grace period gives owners time to fix honest mistakes (like typos, broken links, or missing attributions) before content is hidden.
• If multiple independent reports arrive, or if the issue is severe, the object is hidden immediately.
• Hidden objects disappear from public listings but remain visible to the involved parties for evidence collection.

Dispute Resolution

The preferred outcome is reporter ↔ owner resolution. If an owner fixes the issue and the reporter accepts, the content is restored without escalation.

If no agreement is reached, the case escalates to Uhpenry Review. At that point, communication freezes into read-only mode to preserve evidence integrity. Operators then investigate using the full record of chats, files, and commit data.

Severity Levels

Reports are categorized into four tiers, which determine the response:

• Low: Minor mistakes (typos, broken screenshots). Usually fixed collaboratively.
• Medium: More impactful but non-malicious issues (wrong license text, leaked non-critical keys). May result in warnings.
• High: Harmful or negligent violations (unsafe code, impersonation). Immediate hiding and possible suspension.
• Critical: Dangerous or illegal activity (malware, fraud, criminal content). Permanent bans and legal escalation likely.

Enforcement & Appeals

Consequences scale with severity and user history. Accounts may receive warnings, suspensions, or permanent bans. Importantly, banned accounts are locked but not deleted, preserving the record for audit and appeals.

Users can appeal decisions by submitting new evidence. Appeals are reviewed by a different operator, and all outcomes are logged for transparency.

Safeguards Against Abuse

To prevent the system from being weaponized:

• Rate limits restrict spammy reporting.
• Malicious reporters can be suspended.
• Coordinated attack patterns are detected and triaged manually.

Guidance for Users

• Reporters: Be precise. Provide timestamps, screenshots, commit hashes, and facts, not speculation.
• Owners: Act fast. Fix issues transparently and upload proof (like updated commits or documentation). Proactive licensing and documentation reduce risks of reports.