Trusted network and external sources

Know which relationship you are creating

Trusted Network can establish a mutual connection through a target-bound invitation and share only source-policy-approved moderation summaries. Imports separately configure Discord channels or categories as supported external moderation-log sources with provenance and preview/review.

Verify consent, entitlement, and narrow authority

Trusted Network separates participation, invitation, acceptance, policy, user/case context, evidence request/response, audit, and note-summary approval permissions. External source configuration separately requires import or settings authority plus source visibility and the applicable feature gate.

Open People & Data → Trusted Network for participation, invitations, connections, policy, timelines, alerts, requests, and audit. Open Imports for approved external log sources.

• Explicit agreement from both participating server teams and active Trusted Network entitlement on both servers.
• An authorized target administrator who can accept an expiring invitation.
• A same-server source channel/category with a known supported log family for imports.
• A review plan for provenance, privacy, denied access, and removal.

Invite, accept, set policy, and inspect access

1. 01

   Define the boundary

   Choose either a mutual server trust or an external log source; do not combine the purposes implicitly.

   Check: The administrator knows which data flow is being configured.

2. 02

   Choose the verified Discord identity

   Select an eligible server for a Trusted Network invitation, or select the approved same-server channel/category for imports.

   Check: The configured target resolves from a known live Discord object.

3. 03

   Accept or preview

   Require authorized target acceptance for Network; inspect provider, family, confidence, and unknown preview rows for imports.

   Check: No unilateral relationship or unreviewed imported record is treated as trusted.

4. 04

   Set minimum sharing

   For Network, review your outgoing policy, the partner-controlled incoming policy, note-summary approvals, and private informational alert destination.

   Check: Only necessary redacted categories can cross the connection.

5. 05

   Verify and remove when needed

   Test allowed and denied Network reads and inspect access logs, or inspect import provenance; pause/revoke/remove when the agreement ends.

   Check: Future access stops while provenance and administrative history remain auditable.

Confirm provenance and both trust directions

The server has an explicit, mutually accepted, directionally controlled Network relationship or a configured external source without exposing generic cross-server administration, raw partner data, or arbitrary ingestion.

Separate trust from import sources

Create and remove a trusted relationship

1. 01

   Document the purpose

   State which limited product behavior requires trust, the participating server IDs, responsible leads, and privacy expectations.

   Check: The relationship is specific and reviewable.

2. 02

   Verify mutual consent

   Both server teams confirm the exact relationship through their approved process.

   Check: No one-sided trust is presented as mutual.

3. 03

   Create an expiring invitation

   Choose an eligible ModFlow server from the directory and send the one-time link privately to its authorized administrator.

   Check: No raw ID entry or unilateral row is presented as active trust.

4. 04

   Accept and review both directions

   The target administrator accepts, then each server reviews only its own outgoing policy and the partner-controlled incoming policy.

   Check: The connection is mutual while each sharing direction remains independently controlled.

5. 05

   Verify, pause, or revoke

   Test an authorized and a denied read, inspect the Network access log, then pause or revoke when consent, entitlement, ownership, or purpose changes.

   Check: New access stops immediately while historical provenance and audit state remain honest.

Configure an external source

1. 01

   Identify the provider and log family

   Confirm which bot/system posts the messages and which supported moderation or activity shapes are expected.

   Check: Parser expectations are known.

2. 02

   Choose the exact channel or category

   Resolve the live Discord object and verify bot/staff read permissions.

   Check: The source belongs to the intended server and is accessible.

3. 03

   Preview before reconciliation

   Inspect provider, source, actor, target, occurrence time, confidence, and unknown rows.

   Check: Potential attribution errors are visible before publication.

4. 04

   Publish only supported records

   Confirm ambiguous moderation intentionally; leave unrelated noise outside moderation review and route routine activity to Activity.

   Check: Imported history remains supplemental and source-labeled.

5. 05

   Monitor source health

   Review inaccessible, stale, noisy, or unexpectedly empty source status.

   Check: The team knows when import coverage is incomplete.

Consent, provenance, and removal

• Record who approved the relationship or source, the purpose, and the date it should be reviewed.
• Keep numeric Discord identities and provider labels so display-name changes do not rewrite provenance.
• Do not import from channels/categories the bot or reviewer cannot currently access.
• Removing a source or trusted server stops future use but does not make legitimate historical source labels disappear.
• When a source was configured incorrectly, document the correction and review affected imported records rather than silently relabeling them.
• Never use trust or import features to obtain records from a server that has not consented or to bypass channel visibility.
• Trusted Network shares only allowlisted, source-policy-approved projections. Raw notes and evidence never cross the connection; note summaries require a separate redacted approval.
• Network records and join alerts are informational context for human review and never authorize automatic punishment.

Pause or revoke unsafe access

Both workflows depend on consent, current feature access, narrow staff permissions, source visibility, and supported record shapes. Network summaries can be incomplete, stale, disputed, or wrong; they never grant authority over another server or justify automatic punishment.

Keep trusted sharing narrower than multi-server control

Trusted Network is mutual, invitation-based, directionally configured sharing with source provenance and recipient permissions. Each server controls only what it sends. Generic cross-server administration and centralized reporting remain out of scope. A Premium entitlement does not grant authority over another server.