Trust & Safety

The authoritative trust-and-safety control catalogue for the Sindh IT Portal — Facilitation Desk (SITP): the principles, intake protections, spam and abuse detection, content moderation, false-complaint handling, staff-protection measures, the confidential whistleblower channel, identity-verification appeals, VIP/confidential handling, reporting and blocking, data integrity, PII handling in user-generated content, takedown and legal requests, trust metrics, and the periodic transparency report.

1. How to Read This Document

This document is the single source of truth for trust and safety controls of SITP. It is consumed by engineering (intake hardening, moderation tooling, ABAC scoping), by QA and the abuse-test suite (/specs/en/13-test-strategy/ abuse cases), by the S&ITD Trust & Safety team and Facilitation Desk (moderation workflow), by internal audit (penalty and takedown evidence), and by the PPP contract as the trust-and-safety baseline.

Trust and safety overlaps deliberately with security (/specs/en/11-security-compliance/) and with roles and permissions (/specs/en/04-roles-permissions/). Where they overlap, security defines how the platform resists technical attack (WAF, authn/authz, crypto, audit), roles define who can do what (RBAC + ABAC + overrides), and this document defines how the platform keeps the human discourse on it safe, fair, and lawful — protecting complainants who report in good faith, protecting departments from abuse and fraud, and protecting staff from harassment, while preserving the open, low-friction intake that is the portal's whole purpose.

1.1 Control format

Every control is a row in a per-domain table:

1.2 Domain codes

1.3 Relationship to security and roles

This document references — and does not restate — the technical controls that already live in /specs/en/11-security-compliance/: rate limiting at the edge (SEC-035), the WAF and OWASP CRS (SEC-034), audit append-only and hash-chained logs (SEC-042 to SEC-044), field-level PII encryption (SEC-021), the ABAC layer for confidential/VIP (SEC-009), break-glass (SEC-011), and retention (§16). Trust-and-safety controls sit on top of that foundation: they decide what counts as abuse, what to do about it, and how to keep the people involved safe.

2. Trust & Safety Principles

SITP is an open, public-facing government grievance portal. Openness and safety are not in tension by default — they are jointly achieved by lowering friction for good-faith complainants while raising cost and risk for bad-faith ones. Nine tenets govern every control in this catalogue.

3. Intake Protections

Intake is the portal's front door. It must stay low-friction for genuine complainants while raising the cost of automated and abusive submission. The controls below combine challenges, throttles, and verification at the points most exposed to abuse: login, registration, public ticket filing, anonymous/whistleblower intake, and inbound email/SMS/WhatsApp-to-ticket (see /specs/en/19-multichannel-intake/).

3.1 Rate-limit tiers

The tiers below extend the security baseline (/specs/en/11-security-compliance/ §10) with the intake-channel dimension. A request counts against all applicable scopes (a ticket filed over WhatsApp counts against the per-user, per-IP, and per-channel limits simultaneously); the most restrictive wins.

4. Spam & Abuse Detection

Beyond the perimeter, SITP runs a two-engine detection layer: a deterministic rule engine for fast, explainable signals, and an ML classifier for subtler patterns (semantic similarity, intent). Both are multilingual (EN/UR/SD) and feed the moderation queue in §5.

5. Content Moderation

Flagged content flows into a single moderation work queue governed by clear roles, a fixed action set, and an appeal path. Moderation is human-in-the-loop for every consequential outcome; automation only prepares and prioritises.

5.1 Moderation pipeline

The diagram traces a submission from intake through detection to moderation decision and appeal. The written description follows.

Written description. A submission arrives through any intake channel (web form, inbound email, SMS/WhatsApp-to-ticket, or the whistleblower channel). It first passes the edge controls (§3): CAPTCHA, per-IP/user/channel rate limiting, and bot detection. The detection layer (§4) then scores it with the rule engine and the ML classifier across spam, abusive-language, defamation-risk, and mass-filing signals. A submission scored allow is published or routed normally. A submission scored flag stays visible but enters the moderation queue for review; a submission scored hold (or block, which routes to hold pending confirmation) is hidden from public/department view until reviewed. The moderator (§5) takes one of six actions — approve, hide, remove, warn, suspend, or escalate. Every consequential action triggers a user notification carrying the reason and the appeal path, and is written to the audit log. If the user appeals, a Senior Moderator or Trust Lead who did not take the original action reviews the case and either upholds or overturns it. The pipeline is fail-safe: in detection ambiguity, content is held for review rather than published; in moderation ambiguity, the moderator escalates rather than guessing; and every step — including appeals — is recorded in the append-only, hash-chained audit log.

6. False / Malicious Complaints

A genuine portal must protect departments from complaints filed in bad faith: fabricated grievances, deliberate harassment of officials, extortion attempts, or coordinated defamation. SITP distinguishes unfounded (no wrongdoing found, but filed in good faith — no penalty) from false/malicious (knowingly fabricated or filed to harm). The latter carries consequences, with due process at every rung.

6.1 Penalty ladder

The ladder escalates by severity, intent, and recidivism. Each rung requires a documented reason, an audit entry, a user notification with appeal rights, and — from R2 upward — Senior Moderator / Trust Lead approval. A complainant always retains the right to appeal before a rung takes effect.

Reinstatement path (TS-028). A blacklisted user or company may apply for reinstatement after a documented cooling-off period (default 12 months) by submitting a reinstatement request through the Trust Lead. Reinstatement is conditional — typically re-attestation of identity, reduced filing limits, and a probationary period — and the decision (grant, deny, or grant-with-conditions) is audit-logged and notified.

7. Abuse Against Staff

Government staff resolving tickets are public-facing and exposed to harassment. SITP protects them with controls on the channel (blocking, rate limits) and on the escalation path (law enforcement where conduct becomes criminal).

7.1 Escalation to law enforcement

When conduct directed at staff crosses from abusive into criminal — credible threats of violence, doxxing, extortion, sustained harassment — the matter leaves the platform's enforcement toolkit and enters the legal domain. The procedure is owned jointly by the Trust Lead and the S&ITD legal cell (see /specs/en/22-governance-legal/).

1. Triage. The Trust Lead confirms the conduct meets a criminal threshold and preserves the evidence bundle (audit chain, message snapshots, identity records held under §8/§10 restrictions).
2. Legal review. The S&ITD legal cell reviews the bundle and authorises (or declines) referral, recording the decision and rationale in the audit log.
3. Referral. Where authorised, the matter is referred to the appropriate law-enforcement agency with a formal cover note on S&ITD letterhead (Module L), the evidence bundle made available under controlled disclosure, and identity data released only to the extent the legal basis permits.
4. Platform action. In parallel, the offending account is suspended or blacklisted per the penalty ladder (§6.1, rung R-LE) and the affected staff member is supported per TS-038.
5. Record. The referral, the legal basis, the data disclosed, and the outcome are retained per the records schedule (/specs/en/11-security-compliance/ §16) and surfaced in aggregate on the transparency report.

8. Anonymous / Whistleblower Channel

SITP provides a separate, confidential intake channel for sensitive reports — corruption, misconduct, harassment, fraud — where the reporter's identity must be shielded or withheld entirely. This channel is architecturally distinct from the normal ticketing flow: it uses its own intake, its own storage treatment, and an ABAC-restricted visibility that excludes even roles who would normally see department tickets. The channel operationalises the whistleblower expectation referenced in _context.md §6, /specs/en/04-roles-permissions/ §5 and §13, and the retention row "Whistleblower / anonymous intake" in /specs/en/11-security-compliance/ §16 (10-year, identity-protected retention).

8.1 Whistleblower confidential flow

The diagram shows the architecturally separate path a whistleblower report takes, from anonymous intake through ABAC-restricted triage, and how the reporter is reached only through a tracked token. The written description follows.

Written description. The reporter enters through the dedicated confidential intake — a separate route that requires no login and no identity. The intake applies CAPTCHA, the T4 rate limit, content-hash dedupe, and bot detection, without collecting the identifying signals used on the authenticated flow. If the reporter optionally chooses to share contact details, those details go directly into the PII vault — field-level encrypted, never indexed, never shown beside the report body. The report body and any attachments are anonymised and processed on-prem only; cloud AI/OCR engines are forbidden (mirrors SEC-051). The report enters the Whistleblower Triage queue, whose visibility is ABAC-restricted to a named S&ITD cohort and the configured escalation chain; no department, DG, or Secretary sees it through ordinary RBAC, and ABAC denial is the default. The reporter is reached only through a tracked token (not a login): the triage unit posts status updates and information requests through the token, and cannot surface the reporter's contact details unless the reporter explicitly opted in. If the report is itself a retaliation complaint, it is routed to an independent reviewer who is not the subject of the original report. Every read of the report is individually audit-logged and reviewed for curiosity reading, and the record is retained for 10 years in identity-protected form before archival. Crucially, the report is excluded from cross-ticket search, similarity detection, analytics, and any cloud-bound pipeline, so the channel's promise of confidentiality is enforced architecturally, not merely by policy.

9. Identity-Verification Appeals

Registration uses file-first, verify-in-parallel (_context.md §5): an entity registers, gets an instant Provisional account, can file immediately, and background checks (SECP, FBR/NTN, SRB, PSEB, NADRA for reps, plus domain email) run in parallel to grant the Verified badge — or hold the account if they fail. A hold is not a dead end: the entity may appeal and re-submit. This section governs that appeal.

10. VIP / Confidential Handling

Some tickets are politically sensitive (VIP) or commercially/personally sensitive (Confidential). These are governed by the ABAC layer documented in /specs/en/04-roles-permissions/ §6.3 and §13 and in /specs/en/11-security-compliance/ §5 (SEC-009, SEC-011). This section restates the trust-and-safety contract for that handling and ties it to the controls in this catalogue.

11. Reporting & Blocking

Reporting is the crowd-sourced complement to automated detection: users flag content or other users, and staff apply blocks and suspensions. Both flows feed the moderation queue (§5) and the penalty ladder (§6.1).

12. Data Integrity

Trust depends on the record being truthful: that a complaint was actually filed as shown, that a resolution was actually achieved, that a closure was not fabricated. Integrity controls ensure moderation and enforcement actions — and the tickets they touch — cannot be silently rewritten.

13. PII & Sensitive-Data Handling in User-Generated Content

Users sometimes expose PII accidentally — a CNIC pasted into a public reply, a bank statement attached to a visible thread, a third party's phone number in a screenshot. SITP detects and contains this before it propagates.

14. Takedown & Legal Requests

When a court or a competent government authority orders content removed or an account actioned, SITP follows a documented process that preserves due process, minimises over-removal, and keeps the action transparent in aggregate. This operationalises the legal authority documented in /specs/en/22-governance-legal/.

15. Trust Metrics

Trust-and-safety performance is measured, monitored, and surfaced to the Trust Lead, S&ITD oversight, and (in aggregate) the public. Metrics are wired into the analytics module (/specs/en/17-analytics-kpis/).

16. Transparency Report

Accountability to the public is part of the safety model. SITP publishes a periodic aggregate transparency report so that enforcement is visible in summary while individual cases remain protected.

16.1 Transparency report contents

17. Abuse Categories → Action

This is the operational lookup a moderator applies: given a category of conduct, what is the default action and where does it route. Every cell is reviewable by a human and appealable (TS-019 to TS-021); the defaults below are starting points, not mechanical rules.

18. Control Catalogue Summary

18.1 MoSCoW distribution

19. Open Items [TBD/confirm]

These [TBD/confirm] items are tracked to closure in /specs/en/14-roadmap-release/ and reflected back into this document as the decisions land.

End of document.