Content-moderation policy for submitted ideas

[JSONbored]

Context

#4798's acceptance criteria covers rejecting a malformed or empty idea submission with a clear error, but nothing in this milestone defines what counts as abusive or illegal intent in a well-formed idea, before it consumes paid compute or reaches the execution loop.

Note: the semantic-feasibility engineering half of this issue (adapting feasibility-cli.js's scoring for freeform text, so an out-of-scope/impossible-but-well-formed idea is caught) has been split out into #5671 (Adapt feasibility-cli.js scoring for freeform idea text), which is now open to Gittensor contributors. This issue covers only the content-moderation policy call: defining what counts as abusive, illegal, or Terms-of-Service-violating intent.

Dependencies

Blocked on #4805 (Terms of Service & liability terms) — moderation policy needs to align with the eventual ToS, and on #5671 for the mechanism this policy plugs into.

Requirements

1. Define what counts as abusive, illegal, or eventual-Terms-of-Service-violating intent in a submitted idea.
2. Define the rejection/flagging behavior and any recourse for a rejected submission.
3. Out of scope: the freeform-text feasibility-scoring mechanism itself — see Adapt feasibility-cli.js scoring for freeform idea text #5671.

Deliverables / Acceptance Criteria

• A written content-moderation policy covering abusive/illegal/ToS-violating intent
• Sign-off that the policy aligns with Terms of Service & liability terms #4805's eventual Terms of Service

Links & Resources

• packages/gittensory-miner/lib/feasibility-cli.js (existing structured-issue feasibility gate, a materially different input shape than freeform idea text)
• Adapt feasibility-cli.js scoring for freeform idea text #5671 (the freeform-text feasibility-scoring mechanism split from this issue)
• Terms of Service & liability terms #4805 (Terms of Service, this policy must align with)

---

Part of #4778.

[linear-code]

JSO-3684

[JSONbored]

Decision: Option A — narrow illegal-content-only denylist

Matches GitHub's Acceptable Use Policy structure: prohibits unlawful content (active-attack malware, CSAM, doxxing, IP infringement) while explicitly protecting dual-use/security-research content from a blanket ban. Cheapest to implement and defend, narrowest false-positive rate, and consistent with #4805's "protective but not heavy-handed" direction.

Concrete policy, not just the category label:

• Prohibited: content whose primary purpose is unlawful action (malware for active attacks, generating CSAM, doxxing/harassment tooling, knowing IP infringement).
• Explicitly NOT prohibited on its own: security-research, dual-use, or "could theoretically be misused" content (auth systems, payment flows, file upload, scraping) — matching GitHub's own posture of restricting on confirmed intent/abuse signal, not topic.
• Recourse: auto-reject with a specific policy citation — the category is unambiguous enough that a stated reason is cheap and appropriate here (unlike a broader scope, which would need human review).

Aligns with #4805's now-decided direction (see that issue's comment) — sign-off on that alignment is still pending #4805's actual legal review, per this issue's own dependency. packages/gittensory-miner/lib/feasibility-cli.js's adaptation (#5671) is already closed — this is the policy content to wire into it if it doesn't already accept a configurable denylist; worth a quick check before assuming a new implementation issue is needed here.