Loading
Preparing the latest content.
Use object-level reports for suspicious jobs, Builders, companies, or conversations. The platform can review the target, evidence, history, and safety rules from the right context.
Money
Money pressure usually needs the fastest containment.
Immediate action
Pause deposits, private transfers, training purchases, guarantees, and any payment outside the platform.Data
Data requests can turn a hiring conversation into account or privacy risk.
Immediate action
Stop sending IDs, bank cards, verification codes, passwords, complete resumes, or customer materials.Context
Loose support messages slow review because the target has to be reconstructed.
Immediate action
Report from the object page so the system receives the target type, target ID, and surrounding context.Object-level reports are preferred because the system receives the target type and target ID instead of a loose support message.
Object: Job
Use when
Use when the suspicious claim lives in the listing, requirements, compensation, or hiring identity.
Attached context
Object: Builder
Use when
Use when the risk is tied to a public profile, case material, identity claim, or Builder-side communication.
Attached context
Object: Company
Use when
Use when the company identity, website, hiring authority, or related jobs look inconsistent.
Attached context
Object: Conversation
Use when
Use when the risk appears inside messages and the review needs timestamps or surrounding conversation context.
Attached context
A useful report is concrete enough for review without forcing you to expose more sensitive data.
Include the job, Builder, company, or conversation link. Object-level reports already include target context.
Attach up to 3 JPG, PNG, or WEBP screenshots, 5MB each, especially for payment, contact, or credential requests.
Point to timestamps, off-platform pressure, payment language, threats, privacy exposure, or copied-source links.
Keep transfer requests, deposit language, training purchase links, private phone numbers, emails, or external chat handles.
For employer risk, include company identity, role context, website mismatch, agency confusion, or related job links.
For Builder risk, include copied case sources, impersonation clues, misleading experience, or unsafe conversation context.
These are the current product rules behind the object-level report form.
Reporting should build trust without exposing private records or creating new safety risk.
Support may confirm receipt, ask for more evidence, or share the outcome type when disclosure is safe.
Another user's personal data, internal audit details, and complete enforcement notes are not disclosed.
The public page explains the handling model, not a user-visible progress tracker. Current report progress remains internal until a safe user-facing fact source exists.
Queue state
OpenReview checks
A report record is created with target type, target ID, reason, details, optional evidence, and open-report count for that target.
Review focus
User-facing boundary
Receipt or duplicate-review message.
Queue state
ReviewReview checks
Operations search the queue, inspect attachments, compare target history, and check whether the issue is isolated or repeated.
Review focus
User-facing boundary
May ask for more concrete evidence.
Queue state
ActionReview checks
If the report is actionable, the platform applies the least noisy intervention that contains the risk.
Review focus
User-facing boundary
May share outcome type when safe.
Queue state
ClosedReview checks
Reports are closed as resolved or dismissed, with internal notes kept separate from public feedback.
Review focus
User-facing boundary
No private user data or internal audit notes.