Submissions

Moderated submission rules

What a signal submission requires, how moderation works, and what gets published.

4 min readUpdated 22 Sep 2026/knowledgebase/submission-rules

What a submission is

A signal submission is a report you send to the operator review queue about a specific borrower and a specific event. Submissions are not published automatically. They go through operator review before anything becomes visible in Signal Search.

A published signal changes how other lenders read a borrower, so a person checks each submission for coherence, evidence and language before it goes live.

Auto-Ledger and Warden are separate

A private Auto-Ledger suggestion is not a Signal submission. Accepting or correcting a detected loan changes only that lender's private ledger; it does not publish a warning.

A Warden report is also separate. Warden uses its own restricted intake, evidence, access, and review boundaries. Do not place private payment identifiers, contact details, screenshots, or messages into a public Reddit post to make Auto-Ledger parsing easier.

For machine-readable public loan formats, use the Auto-Ledger posting guide. The format can improve parsing, but it does not submit a Signal or Warden report.

What a submission must include

Every submission that reaches the review queue should have:

1. A specific borrower identifier. The Reddit username, Discord handle, or other platform-specific identity you are reporting on. Use the identifier you actually used when funding or communicating with this borrower.

2. A signal type. The category that best describes what happened: unpaid loan, late repayment, disputed context, or other applicable category. The signal type sets expectations for how reviewers and other lenders will read the result.

3. A source URL or verifiable reference. A link to a thread, post, or community context that provides evidence of the reported event. A submission without a source that an operator can independently check is unlikely to be approved. Screenshots alone are not source URLs. They're supporting evidence, not the primary reference.

4. Relevant dates. When the loan was made, when the due date was, when the default or non-repayment was confirmed, when you last had contact. Dates make the timeline legible.

5. Factual, conservative language. Describe what happened, not what it proves. "Borrower did not repay $150 due on [date] after three contact attempts over 30 days" is appropriate. "Proven scammer" or "fraudulent borrower" are conclusions you are not in a position to certify.

How review works

Submitted material goes to the operator review queue. Operators check:

  • Whether the source URL or evidence supports the claim
  • Whether the language meets publication standards
  • Whether the borrower identifier is specific and traceable
  • Whether the signal type matches the evidence

Submissions can be approved, returned for additional information, or rejected. If a submission is returned, you'll receive a message explaining what's needed. Rejected submissions are archived and do not appear in Signal Search.

Review is not instant. Operators review in sequence. Expect a delay between submission and resolution, especially if your submission needs clarification.

What gets published vs. what stays private

Signal Search shows:

  • Approved signal type (unpaid, late, disputed, etc.)
  • Dates and source context

Signal Search does not show:

  • Your private ledger notes
  • Personal opinions or conclusions
  • Communication content beyond what's needed to establish the event

Your private ledger records are never automatically included in a submission. What you include in a submission is what you choose to include, and it goes through review before it's visible to anyone else.

Before you submit

Ask yourself:

  • Do I have a source URL the operator can verify?
  • Have I waited long enough to be sure this is a default, not a delay?
  • Is my language factual and free of conclusions I can't support?
  • Is the borrower identity specific and accurate?

If the answer to any of these is no, wait. A premature or unsupported submission creates work for the operator and may be returned or rejected. Submitting after the situation is clear produces a stronger, more credible signal.

Publication standards

Published signals use specific, factual language about events. They do not include:

  • Legal conclusions (fraud, theft, criminal intent)
  • Slurs or personal attacks
  • Claims based only on circumstantial evidence
  • Private communication content not directly relevant to the reported event

If a published signal appears to violate these standards, use Suggest an update on the record.