Non-Functional Requirements

The measurable quality attributes — performance, availability, scalability, security, privacy, accessibility, usability, maintainability, observability, reliability, compliance, auditability, interoperability, and portability — that the Sindh IT Portal — Facilitation Desk (SITP) must satisfy for V1. Each requirement states a concrete metric, a measurement method, and a rationale.

1. How to Read This Document

This document is the single source of truth for the non-functional behaviour of SITP. It is consumed by engineering for design and sizing, by QA for acceptance, by security/compliance reviewers for control evidence, and by the PPP contract (MAAHIR / Server4Sale) as the quality baseline.

1.1 NFR format

Every requirement is written as:

### NFR-<CAT>-<nnn> — <title> [M|S|C]

**Metric / Target.** <what is measured and the threshold to meet>
**Measurement method.** <how it is verified — tooling, test, cadence>
**Rationale.** <why this target, and the consequence of missing it>

The trailing badge is MoSCoW (_conventions.md §5): M Must have (V1 launch blocker) · S Should have (V1, soon after launch) · C Could have (nice-to-have in V1 if time). Deferred items are not listed as NFRs; they appear in /specs/en/14-roadmap-release/.

1.2 Category codes

1.3 Targets are V1 baselines

All numeric targets in this document are V1 baselines. They are defensible defaults sized to a single-host Server4Sale deployment (see /specs/en/15-tech-architecture/ §17), calibrated against the reference systems (India CPGRAMS, Pakistan Citizens Portal) and against observed load on comparable provincial portals. They are adjustable: targets marked [TBD/confirm] need confirmation by the named owner before baseline freeze; all others may be revised at each phase review (see §6). Where a target cross-cuts architecture it is linked back to the relevant section of doc 15; where it cross-cuts security controls it is linked to doc 11.

1.4 Measurement conventions

• Latencies are measured at the nginx edge (server-side) unless explicitly client-side, at the p95 percentile over a rolling 30-day window, excluding scheduled maintenance windows.
• Concurrency is measured as authenticated, distinct, active sessions issuing ≥ 1 API call per minute.
• Uptime is measured against the public status page probes (portal + API + docs site), with planned maintenance excluded per §2.2.
• Throughput is measured against the production data set at realistic cardinality (see /specs/en/13-test-strategy/).

2. NFR Template (worked example)

The template below is illustrative only. It is not an NFR. Every subsequent requirement in §3 follows this shape exactly.

### NFR-XX-000 — (template example, not a requirement) [M]

**Metric / Target.** The <quantity> shall be ≤ <value> under <conditions>.
**Measurement method.** Verified by <tool/test> on <cadence>; evidence stored in <location>.
**Rationale.** <Why this matters to users/operations/compliance, and the cost of failure.>

• The ID is stable across EN/UR/SD and never renumbered.
• The title is short and imperative.
• Metric / Target always gives a number (or an explicit [TBD/confirm]), never a qualitative phrase like "fast" or "robust".
• Measurement method names the tool (Loki, Grafana, k6, Lighthouse, axe, OWASP ZAP, etc.) and the cadence (per-release, continuous, quarterly).
• Rationale ties the target to a user outcome, an operational risk, or a compliance obligation.

3. Requirements by Category

3.1 Performance (PERF)

The portal serves citizens, company representatives, and government staff in three scripts on mobile-first networks. Performance targets protect the perceived responsiveness of the core ticket journey (file → track → resolve) and bound the cost of AI/OCR so the long-tail operations never block the short ones.

NFR-PERF-001 — API read latency (p95) [M]

Metric / Target. p95 latency of read API endpoints (GET) shall be ≤ 300 ms at the nginx edge, at up to the V1 concurrency target (see NFR-PERF-008). Measurement method. Continuously, via OpenTelemetry traces and the nginx access log p95 panel in Grafana; alerted in Sentry on breach sustained > 15 min. Rationale. Read paths (ticket lists, dashboards, KB) dominate interactive load; > 300 ms p95 visibly degrades perceived responsiveness on 4G mobile.

NFR-PERF-002 — API write latency (p95) [M]

Metric / Target. p95 latency of write API endpoints (POST/PUT/PATCH for state-changing operations) shall be ≤ 800 ms at the nginx edge, excluding AI/OCR work that is offloaded to BullMQ. Measurement method. Continuously via OTel traces; per-release k6 load test against staging. Rationale. Writes fan out to audit, search index, and notifications queues; the 800 ms budget covers DB transaction + enqueue while heavy work happens asynchronously.

NFR-PERF-003 — Page load — Largest Contentful Paint (LCP) [M]

Metric / Target. LCP on the top 10 portal pages shall be ≤ 2.5 s on a simulated 4G mid-tier mobile device (Moto G Power / Lighthouse "mobile" profile). Measurement method. Per-release Lighthouse CI against the staging build; field data captured via the Real User Monitoring (RUM) integration in Sentry; p75 reported in Grafana. Rationale. 2.5 s LCP is the Google "needs improvement" / "good" threshold and aligns with mobile-first citizen access.

NFR-PERF-004 — AI summary latency [M]

Metric / Target. AI ticket summary generation shall return in ≤ 15 s p95 after submission of an OCR'd ticket, including redaction + LLM call + audit write. Measurement method. BullMQ job duration histogram in Grafana for the ai-summarize queue; p95 panel with 30-day window. Rationale. Summaries are reviewed by staff within the triage flow; > 15 s pushes the user to abandon the assisted path and read the raw ticket.

NFR-PERF-005 — OCR throughput per page [M]

Metric / Target. OCR of a single standard A4 page (≤ 5 MB, 300 DPI) shall complete in ≤ 30 s p95 using the cloud engine and ≤ 60 s p95 using the on-prem Tesseract fallback. Measurement method. ocr-extract queue duration histogram in Grafana, segmented by engine; quarterly benchmark suite of 100 representative documents. Rationale. OCR gates MoM extraction and search indexing; the 30 s ceiling keeps a 10-page MoM upload from blocking the user beyond ~5 minutes.

NFR-PERF-006 — Internal chat message end-to-end latency [S]

Metric / Target. Time from message send to delivery on a connected recipient's WebSocket shall be ≤ 500 ms p95 within a single gateway instance and ≤ 800 ms p95 across instances via the Redis pub-sub adapter. Measurement method. Client-side RUM (send-timestamp vs. receive-timestamp) aggregated in Sentry; server-side OTel span for the gateway message handler. Rationale. Chat is Slack-style; > 500 ms breaks conversational rhythm and drives users off-platform.

NFR-PERF-007 — Database query latency (p95) [M]

Metric / Target. p95 MariaDB query latency (excluding scheduled batch/aggregate jobs) shall be ≤ 100 ms, and the slow-query log threshold shall be 500 ms with zero routine slow queries per day. Measurement method. MariaDB performance schema + the Prometheus exporter; slow-query count panel in Grafana; quarterly EXPLAIN ANALYZE review of the top 20 hottest queries per /specs/en/15-tech-architecture/ §5.5. Rationale. DB is the foundational tier; query latency is the multiplier on every API target above.

NFR-PERF-008 — Concurrent users (V1 target) [M]

Metric / Target. The system shall sustain 5,000 concurrent authenticated users issuing ≥ 1 API call/min, with ≤ 1 % HTTP 5xx and no graceful-degradation fallbacks engaged. [TBD/confirm] — to be validated against the Phase-1 load profile. Measurement method. Per-release k6 soak test against staging at 110 % of the target for 60 minutes; production load confirmed in Grafana at go-live + 30 days. Rationale. 5,000 is a defensible provincial-portal V1 baseline; peak events (ministerial announcements, news cycle) are absorbed by the public-site CDN cache and queue offload.

NFR-PERF-009 — Time to first byte (TTFB) [S]

Metric / Target. TTFB at the nginx edge shall be ≤ 200 ms p95 for cached reads and ≤ 400 ms p95 for uncached dynamic reads. Measurement method. nginx exporter + RUM; per-release k6 ramp against the home, ticket-list, and KB-search paths. Rationale. TTFB is the dominant factor in LCP on slow mobile networks; this is the upstream control for NFR-PERF-003.

NFR-PERF-010 — Search latency [M]

Metric / Target. Meilisearch-backed /search shall return in ≤ 250 ms p95 for the top 10 query shapes (ticket search, KB search, officials search) across EN/UR/Sindhi. Measurement method. OTel span on the search adapter; quarterly benchmark across all three scripts using a 100-query multilingual suite. Rationale. Search is the primary navigation path for staff triage and company self-service; script-handling cost must not double the latency.

NFR-PERF-011 — Notification fan-out latency [S]

Metric / Target. Time from domain event to first outbound channel dispatch (email/SMS/WhatsApp/in-app) shall be ≤ 30 s p95 for immediate-priority notifications and ≤ 5 min p95 for digest batch. Measurement method. BullMQ queue wait-duration histogram per channel; alert if backlog > 1,000 jobs for > 5 min. Rationale. SLA timers depend on prompt delivery of assignment and escalation notifications.

3.2 Availability (AVAIL)

SITP is a public-facing government facilitation channel; outages are visible and reputational. The baseline is single-host on Server4Sale (per /specs/en/15-tech-architecture/ §17, §21) with off-host backups and a documented warm-standby next step.

NFR-AVAIL-001 — Production uptime [M]

Metric / Target. The portal, API, and docs site shall achieve ≥ 99.9 % monthly uptime (= an error-budget of ~43 min/month or ~8.7 h/year), excluding planned maintenance (NFR-AVAIL-002). Measurement method. Public status-page probes (portal home, /api/health, /docs/) at 1-min cadence from two geographic vantage points; monthly report published on the status page. Rationale. 99.9 % is the defensible V1 ceiling for a single-host deployment and matches provincial-portal norms; higher tiers require HA topology deferred to post-V1.

NFR-AVAIL-002 — Planned maintenance window [M]

Metric / Target. Planned maintenance shall occur within a published window (Sunday 02:00–05:00 PKT) and shall not consume more than 6 hours/month of cumulative downtime. Measurement method. Change-management record per maintenance; status page announcement ≥ 72 h in advance for any window > 15 min. Rationale. Predictable, low-traffic windows protect citizen access during business hours and meet the 99.9 % budget when excluded.

NFR-AVAIL-003 — Graceful degradation when AI / 3rd-party down [M]

Metric / Target. If the AI service, an OCR engine, or any external integration (NADRA/SECP/FBR/SRB/PSEB/e-Office, Mailjet/SMS/WA) is unavailable, the core ticket journey (file, track, comment, resolve, close) shall remain fully functional with the dependent capability visibly marked "temporarily unavailable" in the UI. Measurement method. Per-release fault-injection test in staging: each external dependency is killed and the critical user journeys (per /specs/en/10-ux-sitemap-flows/) must pass. Rationale. Citizens must never be blocked from filing because a downstream AI/OCR/integration is down; circuit breakers (NFR-RELY-003) deliver this.

NFR-AVAIL-004 — Disaster Recovery — Recovery Point Objective (RPO) [M]

Metric / Target. RPO shall be ≤ 1 hour (baseline). [TBD/confirm] — to be tightened when the binlog-shipping lag is measured in production (see /specs/en/15-tech-architecture/ §21). Measurement method. Quarterly restore drill (per NFR-MAINT-005); measured lag = now() − latest_binlog_applied_at on the standby target. Rationale. 1 h of lost data is the maximum tolerable for citizen-submitted tickets; current binlog capability supports low single-digit minutes.

NFR-AVAIL-005 — Disaster Recovery — Recovery Time Objective (RTO) [M]

Metric / Target. RTO shall be ≤ 4 hours (baseline) from declaration of incident to full service restoration on the same host. [TBD/confirm] — to be revised when warm-standby topology is in place. Measurement method. Quarterly restore drill timed end-to-end; result attached to the DR runbook. Rationale. A 4-hour outage is within the 99.9 % annual budget and within the tolerance of a facilitation (non-emergency) service.

NFR-AVAIL-006 — Zero-downtime deploys [S]

Metric / Target. Routine application deploys shall incur 0 s of user-visible downtime via nginx draining + rolling container recreation per /specs/en/15-tech-architecture/ §19. Measurement method. Status-page probe rate during each deploy; deploy is rolled back automatically if 5xx rate exceeds 1 % for > 60 s. Rationale. Frequent safe deploys are a precondition for the iteration cadence promised in the PPP.

3.3 Scalability (SCAL)

V1 is sized for one host; the architecture (doc 15 §4, §20) keeps scale-out a refactor, not a rewrite. Targets here describe the headroom and the growth runway.

NFR-SCAL-001 — Horizontal scaling of stateless services [M]

Metric / Target. The NestJS API, the WebSocket gateway, the FastAPI AI service, and each BullMQ worker pool shall be horizontally scalable with no code change — only a replica count change + a Redis pub-sub join. Measurement method. Architecture review per release confirms no in-process state; staging test runs 2× API replicas behind the same Redis. Rationale. Locks the modular-monolith's stated promise (doc 15 §1) that scale-out is configuration, not engineering.

NFR-SCAL-002 — Queue-based load leveling for OCR / AI / exports [M]

Metric / Target. OCR, AI, exports, notification fan-out, and digest jobs shall run only through BullMQ queues with per-class worker pools; the request path shall never block on these. Measurement method. Static gate in CI: any direct call from a controller/handler to an OCR/AI/export/notify implementation (bypassing the queue) fails the build. Rationale. Protects API latency (NFR-PERF-001/002) from long-tail AI/OCR cost and prevents one slow engine from starving others.

NFR-SCAL-003 — Database read replicas — forward path [C]

Metric / Target. The data layer shall be structured so that introducing MariaDB read replicas for analytics (Metabase) and read-heavy public paths requires only a Prisma read/write split configuration — no schema or query change. Measurement method. Architecture review at Phase 2 gate confirms write-primary/read-replica routing is wired in code (even if single-primary today); lag-skip threshold configurable. Rationale. Preserves the documented next step in /specs/en/15-tech-architecture/ §5.6 without a future rewrite.

NFR-SCAL-004 — Ticket volume growth runway [M]

Metric / Target. The data model, indexes, and partitioning (audit table partitioned by month per doc 05) shall support 100,000 new tickets/year for 5 years (≈ 500 k live tickets) without schema refactor; archive/purge per NFR-PRIV-007. Measurement method. Annual capacity review against real ticket volume; quarterly slow-query review (NFR-PERF-007); partition prune check. Rationale. Provincial-portal growth assumption; ticketing tables are write-once + soft-delete so scaling is linear in inserts.

NFR-SCAL-005 — Registered user growth runway [M]

Metric / Target. The system shall support 100,000 registered company representatives and 10,000 government staff accounts without performance regression at the V1 hardware allocation. Measurement method. Load test at 2× the target cardinality in staging; RBAC-resolution cache hit rate ≥ 95 % in production (NFR-OBS-001). Rationale. Sized against Sindh's IT-sector company count + all provincial department staff over a 5-year horizon.

NFR-SCAL-006 — CDN and edge caching [S]

Metric / Target. Static assets (portal bundles, docs site, public images) shall be served via a CDN in front of nginx; cache-hit ratio ≥ 90 % for static asset requests at the edge. Measurement method. CDN dashboard; per-release check that the home page and the top KB articles are CDN-cacheable. Rationale. Reduces origin load and improves LCP (NFR-PERF-003) for citizens on mobile.

3.4 Security (SEC)

Security controls cross-reference /specs/en/11-security-compliance/ for the authoritative control catalogue. NFRs here state measurable thresholds.

NFR-SEC-001 — OWASP ASVS L2 conformance [M]

Metric / Target. The application shall satisfy OWASP Application Security Verification Standard (ASVS) Level 2 in full before production go-live. Measurement method. Independent security assessment against the ASVS v4 L2 checklist before launch; gaps tracked to closure with a signed remediation plan. Rationale. ASVS L2 is the appropriate bar for a public government system handling PII and citizen-facing workflows.

NFR-SEC-002 — Encryption in transit [M]

Metric / Target. All external traffic shall use TLS 1.2+ (TLS 1.3 preferred); TLS 1.0/1.1 disabled; HSTS with max-age ≥ 31536000; includeSubDomains; preload; rating A or A+ on SSL Labs. Measurement method. Continuous SSL Labs monitor; nginx config review per release. Rationale. Baseline transport security for any system accepting PII over the internet.

NFR-SEC-003 — Encryption at rest [M]

Metric / Target. MariaDB (TDE or table-level), MinIO buckets, backups, and Keycloak realm exports shall be encrypted at rest with AES-256 (or stronger); keys held in the secrets vault, never in images or repos. Measurement method. Configuration audit per release; quarterly key-rotation compliance check; verify backup decrypt-and-read in the restore drill (NFR-MAINT-005). Rationale. Protects PII and audit data if storage media is exfiltrated; supports NFR-PRIV and NFR-COMP obligations.

NFR-SEC-004 — Two-factor authentication for staff [M]

Metric / Target. 2FA shall be mandatory for all government staff accounts (TOTP primary; SMS OTP fallback where device support is limited); company representatives shall be offered 2FA opt-in, with mandatory 2FA on step-up actions (NFR-SEC-005). Measurement method. Keycloak policy enforcement; weekly compliance report listing any staff account without 2FA enrolled. Rationale. Staff accounts have privileged access to citizen PII across departments; mandatory 2FA is the baseline defence against credential compromise.

NFR-SEC-005 — Step-up authentication for sensitive actions [M]

Metric / Target. Sensitive actions — closing a VIP/confidential ticket, deleting a record, exporting sensitive analytics, changing a Primary Authorized Rep, changing a feature flag — shall require step-up auth (recent re-authentication ≤ 5 min, or fresh 2FA challenge). Measurement method. CI test per sensitive route asserts that a stale-session request returns a step-up challenge; security review confirms the route list per release. Rationale. Limits blast radius of a hijacked staff session, especially for irreversible or PII-exporting actions.

NFR-SEC-006 — Secrets management — no secrets in repo/images [M]

Metric / Target. No DB password, API key, signing key, or provider credential shall appear in source control, container images, build logs, or runtime env files on disk; all shall be fetched from the secrets vault (HashiCorp Vault or Server4Sale-managed) at startup. Measurement method. Pre-commit secret scanner (e.g., gitleaks/trufflehog) in CI; image scan for secrets; quarterly vault-access audit. Rationale. Prevents the most common cause of credential leakage in government systems.

NFR-SEC-007 — Pre-launch and annual penetration testing [M]

Metric / Target. An independent external penetration test shall be completed before public go-live, and at least annually thereafter, and after any security-sensitive change. Critical findings remediated within 30 days; high within 60 days. Measurement method. Pen-test report on file; finding-tracker with SLA; closure evidence reviewed at the phase gate. Rationale. Independent validation is required for the ASVS L2 posture and for CII registration (NFR-COMP-005).

NFR-SEC-008 — Web Application Firewall (WAF) [M]

Metric / Target. nginx shall run a WAF with the OWASP Core Rule Set in front of the API and the portal; default-deny on rule-set criticals; tuning exceptions reviewed monthly. Measurement method. WAF log review; quarterly false-positive review; ModSecurity audit log retained 90 days. Rationale. First-line defence against common web attacks; complements ASVS-driven app-layer controls.

NFR-SEC-009 — Rate limiting [M]

Metric / Target. Rate limits shall be applied per user, per IP, and per tenant at: login/OTP endpoints (≤ 10/min/IP); ticket creation (≤ 30/min/user); AI/OCR endpoints (≤ 20/min/user); search (≤ 60/min/user). Public (unauthenticated) endpoints throttled more aggressively. Measurement method. @nestjs/throttler config + nginx limit-req; Grafana panel of throttled requests; alert if a throttle fires > 1,000×/min (potential abuse). Rationale. Protects against brute force, enumeration, and resource exhaustion; underpins NFR-USA-005 trust-and-safety.

NFR-SEC-010 — Secure HTTP headers [M]

Metric / Target. All responses shall set Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY or CSP frame-ancestors 'none', Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy restrictive defaults. Measurement method. Mozilla Observatory / observatory.mozilla.org target A or higher; header check in CI per release. Rationale. Baseline browser-layer hardening; cheap and high-impact.

NFR-SEC-011 — Dependency / SCA scanning [M]

Metric / Target. All dependencies (npm, pip, container base images) shall be scanned for known vulnerabilities (SCA) on every build and nightly; critical CVEs (CVSS ≥ 9.0) in production dependencies remediated within 7 days, high (CVSS 7.0–8.9) within 30 days. Measurement method. SCA tool (e.g., Dependabot / Snyk / Trivy) integrated in CI; dashboard of open findings by severity and age. Rationale. Most real-world breaches route through stale dependencies; continuous SCA is the minimum bar.

NFR-SEC-012 — Upload anti-malware scan [M]

Metric / Target. Every uploaded file shall be quarantined until ClamAV returns clean; infected files isolated, never visible to other users; audit event raised; requester notified in-app. Zero infected files released to general access. Measurement method. ClamAV worker metrics; quarterly seeded-EICAR test in staging; file-access audit trail check. Rationale. Uploads are a primary attack vector for malware propagation and content injection.

NFR-SEC-013 — Session and token hygiene [M]

Metric / Target. Access tokens ≤ 15 min lifetime; refresh tokens ≤ 7 days with rotation on use; revocation propagates to Redis denylist within ≤ 5 s; idle session timeout ≤ 30 min for staff UI, ≤ 24 h for citizen UI. Measurement method. Keycloak policy + token inspection test in CI; revocation-latency test on logout. Rationale. Bounds the window of a stolen token; aligns with government-session norms.

3.5 Privacy / Data Protection (PRIV)

SITP processes personal data of company representatives and government staff, plus sovereign data (CNIC, NADRA payloads). Privacy obligations follow the Sindh Right to Information (RTI) Act 2016 (which governs access to public information) and general data-protection principles (minimization, purpose limitation, security, retention). See /specs/en/11-security-compliance/.

NFR-PRIV-001 — Data minimization [M]

Metric / Target. Each form and API payload shall collect only the fields justified by a documented purpose; "nice-to-have" fields flagged in design review and removed unless justified. Measurement method. Privacy review per feature (data-protection-by-design checklist); field inventory maintained per table in /specs/en/05-data-model/. Rationale. First principle of data protection: do not collect what you do not need.

NFR-PRIV-002 — Consent and preference management [M]

Metric / Target. Every user shall have a consent and preference record capturing: notification channel opt-ins (email/SMS/WhatsApp/in-app), marketing/digest opt-in (separate from transactional), and language preference. Consent shall be withdrawable in one click per channel. Measurement method. Preference-center UI test; audit log of consent changes; quarterly report on opt-out rates. Rationale. Channel consent is a baseline expectation and a precondition for non-spammy notifications.

NFR-PRIV-003 — PII vaulting and encryption [M]

Metric / Target. PII fields (CNIC, phone, email, home address, biometric-like data) shall be encrypted at column level (separate from at-rest DB encryption) or stored in a dedicated PII vault table with a reversible token in the host table; access to decrypt shall be role-bound and audit-logged. Measurement method. Schema review (doc 05 §9 data-classification); query audit log reports all PII-decrypt events; pen-test verifies no plaintext PII in standard dumps. Rationale. Limits blast radius of a DB read compromise; supports NFR-SEC-003.

NFR-PRIV-004 — Right to erasure (with retention exceptions) [S]

Metric / Target. A user may request erasure of their personal data; the system shall action within 30 days, except where data is subject to a legal retention obligation (audit log, tax records, ongoing-ticket evidence, Sindh Archives rules) — in which case the data shall be minimised/anonymised and the exception recorded. Measurement method. Data-subject-request (DSR) workflow test; quarterly DSR report; legal-exception log. Rationale. Aligns with general data-protection principles while respecting the government-records retention regime.

NFR-PRIV-005 — Data classification [M]

Metric / Target. Every table and every API field shall be tagged with one of four data classes — Public / Internal / Confidential / Restricted — driving encryption, access, redaction, and retention behaviour. No untagged PII-bearing column at go-live. Measurement method. Schema review per /specs/en/05-data-model/ §9; CI gate refuses migration that adds an untagged text/JSON column in a PII-bearing table. Rationale. Classification is the precondition for every downstream privacy and security control.

NFR-PRIV-006 — PII redaction before any cloud AI call [M]

Metric / Target. Before any payload is sent to a cloud AI/OCR engine, PII shall be redacted by the on-prem redaction layer; the policy/feature-flag selector shall forbid cloud engines for Restricted data classes (raw CNIC, NADRA payloads, confidential/VIP tickets). Measurement method. Per-call audit row records redaction count and engine; quarterly redaction test with a synthetic PII-bearing corpus; selector-policy test in CI. Rationale. Sovereign data must not leave the trusted boundary; cloud engines used only for permitted classes. See /specs/en/15-tech-architecture/ §6.2, §6.4.

NFR-PRIV-007 — Retention and purge schedule [M]

Metric / Target. Every data class shall have a documented retention period; expired data shall be purged or archived by a scheduled worker per schedule; presigned URLs expire in ≤ 15 min; soft-deleted records hard-purged after the class retention window. Measurement method. Retention schedule published in /specs/en/11-security-compliance/; monthly purge-job success report; quarterly link-expiry test. Rationale. Bounds data-at-risk; aligns with NFR-COMP records-management obligations.

NFR-PRIV-008 — Data residency (Pakistan) for sensitive data [M]

Metric / Target. All production personal data and sovereign-data payloads (CNIC, NADRA lookups, ticket content) shall reside on infrastructure within Pakistan (Server4Sale); cross-border transfer is permitted only for aggregated, anonymised, or PII-redacted payloads and only to providers with documented data-processing terms. Measurement method. Hosting-topology review confirms Pakistan residency; AI-engine selector policy reviewed per release; vendor DPA on file for any cross-border processor. Rationale. Provincial/national expectation for citizen data sovereignty; supports NFR-COMP-004.

3.6 Internationalization (I18N)

SITP serves three languages — English (master/source), Urdu, Sindhi — with RTL for Urdu and Sindhi, and a dual Gregorian + Hijri calendar. See /specs/en/09-i18n-localization/.

NFR-I18N-001 — Three languages, full parity [M]

Metric / Target. 100 % of user-facing strings in the portal and the docs site shall be translated and published in EN, UR, and Sindhi at go-live; no untranslated string in a V1 user journey. Measurement method. CI check on string catalogs: every key present in EN must be present in UR and SD; pre-release translation-completeness report. Rationale. Sindhi and Urdu are statutory-provincial languages; partial translation undermines the product mission.

NFR-I18N-002 — Right-to-left (RTL) support [M]

Metric / Target. The portal and docs site shall render fully in RTL when the user locale is UR or SD; layout shall use logical CSS properties (padding-inline-start, etc.) so a single component tree serves both directions; no inline direction hacks. Measurement method. Visual regression test for both LTR and RTL on the top 20 pages; per-release RTL review. Rationale. RTL is a baseline accessibility and usability requirement for Sindhi/Urdu readers.

NFR-I18N-003 — No hardcoded user-facing strings [M]

Metric / Target. Zero hardcoded user-facing strings in source; all strings externalized to locale catalogs; CI gate fails the build on a hardcoded string in a user-facing component. Measurement method. Lint rule (e.g., eslint-plugin-react-intl or equivalent) in CI. Rationale. Hardcoded strings are the leading cause of incomplete translations.

NFR-I18N-004 — Locale per user, propagated everywhere [M]

Metric / Target. Each user shall have a locale (EN/UR/SD) stored on the account, propagated in the JWT and every job payload, and applied to templates, search ranking, AI translation, dates, and numbers. Measurement method. Architecture review (per /specs/en/15-tech-architecture/ §15); end-to-end test setting locale UR and verifying notification emails + AI summaries arrive in UR. Rationale. Locale must not require re-prompting; one source of truth drives every downstream rendering choice.

NFR-I18N-005 — Dual Gregorian + Hijri calendar [M]

Metric / Target. All user-facing dates shall display both Gregorian and Hijri forms (government convention); storage is always UTC Gregorian, Hijri derived at presentation; date/number formatting locale-aware (PKR currency, Urdu/Sindhi numerals optional). Measurement method. UI test on a representative sample of date-bearing screens (ticket list, MoM, letters); calendar widget renders both. Rationale. Government letters and official records conventionally cite both calendars.

NFR-I18N-006 — Glossary consistency [M]

Metric / Target. All UR and SD translations shall use the approved terms from _glossary.md; AI translation (capability #6) shall receive the glossary as injection constraints. Measurement method. CI glossary-conformance check on translation files; quarterly reviewer audit of glossary drift; glossary additions tracked. Rationale. Inconsistent translation of domain terms (e.g., "ticket" vs "complaint" vs "application") undermines user trust and search.

3.7 Accessibility (A11Y)

Accessibility is statutory-adjacent for a government service and is a locked decision in _context.md §2: WCAG 2.1 AA across all three languages.

NFR-A11Y-001 — WCAG 2.1 AA conformance [M]

Metric / Target. The portal and the docs site shall conform to WCAG 2.1 Level AA at go-live; zero critical violations (per automated + manual audit) on the top 20 pages. Measurement method. Automated axe/pa11y in CI per page; per-release manual audit on a representative sample using screen readers (NVDA on Windows, VoiceOver on iOS). Rationale. Accessibility is a baseline obligation for a public-service system, not an enhancement.

NFR-A11Y-002 — Screen-reader support [M]

Metric / Target. All interactive elements shall be operable with NVDA + Firefox, JAWS + Edge, VoiceOver + Safari/iOS, and TalkBack + Android; ARIA semantics correct on dynamic regions (ticket threads, dashboards, chat). Measurement method. Per-release screen-reader test on the critical user journeys; defect list triaged by severity. Rationale. Screen-reader users are the primary beneficiaries of AA conformance.

NFR-A11Y-003 — Full keyboard navigation [M]

Metric / Target. 100 % of functionality shall be operable from the keyboard with a visible focus indicator; logical tab order; no keyboard traps; skip-to-content link on every page. Measurement method. Keyboard-only walkthrough per release; CI check on focus management. Rationale. Keyboard operability is WCAG 2.1 AA (Level A + AA) and a precondition for many assistive technologies.

NFR-A11Y-004 — Colour contrast [M]

Metric / Target. Text contrast shall meet 4.5:1 (normal text) and 3:1 (large text) against its background, across all three language themes (including Ajrak-inspired indigo/maroon palette — see /specs/en/16-branding-design-system/). Measurement method. Automated contrast check per component in CI; manual review of the brand palette tokens. Rationale. Required by WCAG AA; the Ajrak palette needs deliberate token selection to pass.

NFR-A11Y-005 — Sign-language video (Phase 2) [C]

Metric / Target. Pakistan Sign Language (PSL) sign-video guides for the top 5 help topics and the core filing journey shall be available in Phase 2. Measurement method. Phase-2 release gate; content review by a sign-language consultant. Rationale. Supports Deaf citizens; deferred to Phase 2 to align with content-production capacity.

NFR-A11Y-006 — Voice navigation and dyslexia-friendly mode (Phase 2) [C]

Metric / Target. A dyslexia-friendly mode (font, spacing, line-height toggles) and voice navigation for the top user journeys shall be available in Phase 2. Measurement method. Phase-2 release gate; usability test with representative users. Rationale. Inclusive design beyond the AA baseline; deferred to Phase 2.

3.8 Usability (USA)

Usability targets keep the citizen and staff experiences low-friction and consistent. Cross-references /specs/en/10-ux-sitemap-flows/.

NFR-USA-001 — Three-click rule for the company journey [M]

Metric / Target. From landing on the portal, a verified company representative shall reach the file-a-ticket form, the track-my-tickets list, and the KB search in ≤ 3 clicks. Measurement method. Per-release click-path test on the home page in each language; UX review sign-off. Rationale. Reduces drop-off on the most important citizen journeys; benchmarked against CPGRAMS/PCP.

NFR-USA-002 — Role-scoped dashboards [M]

Metric / Target. Each of the 7 roles (citizen/company rep, filer, primary rep, section staff, dept head, DG/Secretary, super admin, plus the public transparency dashboard) shall have a dashboard that surfaces only role-relevant information and actions; no cross-role data leakage. Measurement method. Per-release RBAC + dashboard review; UI test per role against the permission matrix in /specs/en/04-roles-permissions/. Rationale. Information overload and over-broad access are the two biggest staff-UX failure modes.

NFR-USA-003 — Progressive disclosure [S]

Metric / Target. Forms and detail views shall use progressive disclosure (advanced options collapsed by default; rarely-used actions behind "More"); the default view shows the smallest complete path. Measurement method. UX heuristic review per release; field-usage analytics show that collapsed fields are used by < 20 % of submitters. Rationale. Lowers cognitive load for first-time filers; advanced users still reach full capability.

NFR-USA-004 — Consistent design system [M]

Metric / Target. All UI shall be built from the SITP design system (shadcn/ui + the brand tokens from /specs/en/16-branding-design-system/); ≥ 95 % of components in any page come from the system library, not one-off implementations. Measurement method. Component-usage lint in CI; quarterly design-system drift audit. Rationale. Consistency drives perceived quality, accessibility, and maintenance cost.

NFR-USA-005 — Mobile-first responsive + PWA offline intake [M]

Metric / Target. The portal shall be mobile-first responsive (320 px → 1920 px breakpoints tested) and the field-intake flow (offline draft tickets with save-later) shall work as a PWA offline: drafts persist locally and sync on reconnect. Measurement method. Per-release responsive test on real devices; offline-mode test (airplane mode → draft → reconnect → sync). Rationale. Mobile is the primary citizen device; offline intake supports staff and citizens on unreliable networks.

NFR-USA-006 — System usability scale (SUS) baseline [S]

Metric / Target. Post-launch usability testing with representative users in each language shall achieve a System Usability Scale (SUS) score ≥ 70 (industry "acceptable" threshold). Measurement method. Moderated usability test (n ≥ 8 per role per language) at Phase-1 close and annually. Rationale. A measurable, comparable usability benchmark, not just heuristics.

3.9 Maintainability (MAINT)

Maintainability protects the PPP delivery model: MAAHIR (and any successor) must be able to extend and operate the system across the contract lifecycle. See /specs/en/15-tech-architecture/ §1 (modular monolith) and §4 (module map).

NFR-MAINT-001 — Modular monolith structure [M]

Metric / Target. The NestJS deployment shall be a modular monolith with strongly bounded modules; cross-module access shall go through a module's published interface, not its internal services/tables. No circular module dependencies. Measurement method. Architecture lint (e.g., dependency-cruiser / Madge) in CI; module-boundary violations fail the build. Rationale. Preserves the option to extract any module to a microservice later (doc 15 §1); lowers the cost of the PPP exit/handover.

NFR-MAINT-002 — Test coverage [M]

Metric / Target. Automated test coverage shall be ≥ 70 % line and ≥ 60 % branch for the NestJS API and the FastAPI AI service at go-live, sustained per release; critical paths (auth, ticket lifecycle, audit, files) at ≥ 80 % line. Measurement method. Coverage gate in CI on pull request; published coverage report per build. Rationale. Coverage floor is the baseline safety net for frequent deploys; critical paths merit a higher bar.

NFR-MAINT-003 — Mandatory code review + lint + typecheck gates [M]

Metric / Target. No code reaches main without (a) at least one approving review, (b) green lint, (c) green typecheck, (d) green unit tests, (e) green SCA scan. Branch protection enforces all five. Measurement method. Branch-protection config audit; merge evidence in the PR record. Rationale. Process-level guardrail that underwrites every other quality attribute.

NFR-MAINT-004 — Documented APIs (OpenAPI) [M]

Metric / Target. 100 % of public REST endpoints shall be documented in an OpenAPI 3.x spec generated from the code; spec published at /api/openapi.json and rendered at /api/docs; examples and error responses included. Measurement method. CI check that every controller route has OpenAPI metadata; spec-diff gate on breaking changes (per NFR-INTER-004). Rationale. The API is a contract with partners, the mobile app, and Metabase; documented APIs are non-negotiable for an API-first system.

NFR-MAINT-005 — i18n string externalization [M]

Metric / Target. All user-facing strings (portal, docs, notifications, emails, SMS, WhatsApp templates, letters) shall be externalized to locale catalogs; CI refuses a build with a hardcoded user-facing string (mirrors NFR-I18N-003, restated as a maintainability gate). Measurement method. Lint rule in CI; per-release catalog-completeness report. Rationale. Externalization is the precondition for adding a fourth language without code change.

NFR-MAINT-006 — Restore drills (DR rehearsal) [M]

Metric / Target. A full restore drill shall be executed at least quarterly, restoring MariaDB, MinIO, and Keycloak to an isolated environment and verifying checksums; results attached to the DR runbook. Measurement method. Drill record per quarter; checksum report; gap list tracked. Rationale. Untested backups are theatre; quarterly drills validate NFR-AVAIL-004/005.

NFR-MAINT-007 — Code-comment and runbook currency [S]

Metric / Target. Every module shall have a top-of-file purpose comment; every operational procedure (deploy, rollback, restore, incident) shall have a runbook reviewed at least annually and after any relevant change. Measurement method. Annual doc-freshness audit; runbook last-updated date tracked. Rationale. Knowledge transfer is a core PPP exit safeguard.

3.10 Observability (OBS)

Observability is wired from day one — not bolted on (doc 15 §1, §18). Targets here define what "observable" means measurably.

NFR-OBS-001 — Centralized structured logging [M]

Metric / Target. All services shall emit structured JSON logs shipped to Loki; every log entry carries trace_id, user_id (where applicable), module, level, and timestamp; PII never logged (redaction enforced). Measurement method. Log-schema validator in CI; Loki query sample per release; quarterly PII-in-logs scan. Rationale. Structured correlated logs are the basis of incident diagnosis and audit forensics.

NFR-OBS-002 — Metrics + dashboards [M]

Metric / Target. Grafana dashboards shall cover: API latency/throughput/error-rate, DB query latency + slow queries, Redis/queue depths, AI/OCR job durations, notification delivery rates, login/2FA events, and the four golden signals (latency, traffic, errors, saturation) per service. Measurement method. Dashboard-inventory review at each phase gate; alert wiring test. Rationale. "If it's not on a dashboard, it doesn't exist" — operational visibility baseline.

NFR-OBS-003 — Distributed tracing [M]

Metric / Target. OpenTelemetry traces shall span the NestJS API → BullMQ workers → FastAPI AI service → external adapters, with a propagated trace_id so a single user action is traceable end-to-end. Sample rate configurable; 100 % for error paths. Measurement method. Trace-completeness test in staging: a representative ticket-file action produces a single connected trace across all tiers. Rationale. End-to-end tracing is the only way to diagnose latency in a multi-tier async system.

NFR-OBS-004 — Error tracking + alerting [M]

Metric / Target. Sentry (or equivalent) shall capture client- and server-side errors with release health + source maps; page-load error rate ≤ 1 %; unhandled server exceptions paged to on-call within 5 min; alert noise reviewed monthly (target: < 10 alerts/day, > 90 % actionable). Measurement method. Sentry dashboard; on-call paging log; monthly alert-tuning review. Rationale. Visible errors + low-noise alerting are the precondition for sustainable on-call.

NFR-OBS-005 — Public status page + uptime probes [M]

Metric / Target. A public status page shall report portal, API, docs site, AI/OCR, and notification-channel health, updated at 1-min cadence; incident communications published within 15 min of declaration. Measurement method. Status-page uptime report; incident-postmortem review of comms timeliness. Rationale. Public trust depends on visible, honest status reporting.

NFR-OBS-006 — Correlation IDs end-to-end [M]

Metric / Target. Every inbound request shall be assigned a trace_id at the edge (nginx), propagated through every service call, every BullMQ job, every outbound integration call, and included in every notification metadata. The trace_id shall be returnable to the user as a support reference. Measurement method. Verified per release by a synthetic end-to-end test that asserts the same trace_id appears in the nginx log, the API log, a worker log, the AI-service log, an integration-call record, and an audit row. Rationale. Without correlation IDs, citizen support queries ("my ticket didn't file") cannot be diagnosed.

NFR-OBS-007 — Audit visibility into AI usage [M]

Metric / Target. Every AI/OCR call shall produce an immutable audit row recording engine, feature, sensitivity class, redaction count, latency, token/cost, and outcome; a Grafana panel tracks AI spend, error rate, and engine mix. Measurement method. AI-audit row completeness test in CI; monthly AI-cost report. Rationale. AI cost governance and accountability require call-level visibility.

3.11 Reliability / Robustness (RELY)

Reliability targets ensure the system degrades predictably when external dependencies (NADRA, SECP, FBR, SRB, PSEB, e-Office, Mailjet, SMS, WhatsApp, AI providers) misbehave. Cross-references /specs/en/15-tech-architecture/ §13.

NFR-RELY-001 — Graceful handling of 3rd-party outages [M]

Metric / Target. For every external integration, an outage shall result in (a) the dependent action queued-or-failed-with-clear-user-message, (b) zero unhandled exceptions, (c) zero data corruption, (d) auto-recovery when the integration returns. Measurement method. Per-release fault-injection test per adapter (kill the upstream, exercise the path, restore). Rationale. External systems are outside SITP's control but inside the citizen experience.

NFR-RELY-002 — Retries with exponential backoff + jitter [M]

Metric / Target. Every outbound integration call shall retry with exponential backoff + jitter, max attempts configurable per adapter (default 5), then dead-letter; retries never double-write (idempotency keys, NFR-RELY-005). Measurement method. Retry-policy unit test per adapter; dead-letter queue monitor + alert. Rationale. Standard pattern for transient-failure resilience; bounds thundering-herd risk.

NFR-RELY-003 — Circuit breakers per adapter [M]

Metric / Target. Each integration adapter shall be fronted by a circuit breaker (e.g., Opossum) that opens after a configurable failure threshold (default 5 consecutive failures / 50 % in 30 s) and half-open probes after a cooldown (default 30 s). Measurement method. Circuit-state metrics per adapter in Grafana; quarterly breaker test in staging. Rationale. Prevents a single failing dependency from cascading into resource exhaustion.

NFR-RELY-004 — Idempotent writes [M]

Metric / Target. Every state-changing API endpoint and every outbound integration call shall be idempotent under a client-supplied or generated idempotency key; retries (network, user double-click, worker redelivery) shall never produce duplicate state. Measurement method. Per-endpoint idempotency test in CI (same payload + key twice → same result, one write). Rationale. Idempotency is the foundation that makes retries safe (NFR-RELY-002).

NFR-RELY-005 — Queue durability [M]

Metric / Target. BullMQ queues shall be durable (Redis AOF persistence enabled, per doc 15 §3); a worker or Redis restart shall not lose enqueued jobs; jobs acknowledged only after successful completion or dead-lettering. Measurement method. Quarterly chaos test: enqueue N jobs, restart Redis + workers, assert all N completed or dead-lettered, none lost. Rationale. Queue durability is what makes async OCR/AI/notification work safe.

NFR-RELY-006 — Database transaction integrity [M]

Metric / Target. Multi-aggregate domain operations shall use explicit MariaDB transactions; long-running work shall be moved out of the DB transaction (enqueue within transaction, do work after commit) so row-lock dwell is bounded. Measurement method. Architecture review per feature; slow-lock monitor in performance schema. Rationale. Protects concurrency and throughput under load (doc 15 §4 cross-cutting mechanics).

3.12 Compliance (COMP)

Compliance obligations derive from Sindh and Pakistan statutes and from government records-management norms. Authoritative controls live in /specs/en/11-security-compliance/; NFRs here state measurable conformance.

NFR-COMP-001 — Sindh RTI Act 2016 alignment [M]

Metric / Target. RTI-category tickets shall be processed and tracked against the statutory deadlines of the Sindh Transparency & Right to Information Act 2016; the SLA engine shall apply the RTI calendar automatically and the public transparency dashboard shall report RTI-compliance rates. Measurement method. Functional test of the RTI SLA path per release; quarterly RTI-compliance report on the public dashboard. Rationale. RTI deadlines are statutory, not policy; non-conformance has legal exposure.

NFR-COMP-002 — Data-protection principles [M]

Metric / Target. The system shall demonstrate conformance to general data-protection principles (lawfulness, fairness, transparency, purpose limitation, minimization, accuracy, storage limitation, integrity, accountability) via the privacy controls in NFR-PRIV-001…008; a data-protection impact assessment (DPIA) shall be on file before go-live. Measurement method. DPIA signed off at the Phase-1 gate; annual refresh. Rationale. Provincial expectation + preparation for any future Pakistan federal data-protection law.

NFR-COMP-003 — Audit-log immutability + retention [M]

Metric / Target. The audit log (aud_event) shall be append-only (no UPDATE/DELETE at the DB privilege level), partitioned by month, retained for ≥ 7 years (or longer per Sindh Archives rules), and exported to off-host storage with hash chaining for tamper-evidence. Measurement method. DB-privilege audit confirms no role has UPDATE/DELETE on aud_event; quarterly hash-chain verification; off-host export success monitor. Rationale. Audit integrity underwrites every other compliance claim (RTI, AG/PAC audit, disputes).

NFR-COMP-004 — Records management per Sindh Archives [M]

Metric / Target. Records (tickets, MoMs, letters, resolutions) shall be retained and archived per Sindh Archives rules; an archival workflow moves expired records to long-term storage with index preservation; disposal is documented and approved. Measurement method. Records-management procedure published; annual archival audit. Rationale. Government records have statutory retention that overrides generic data-minimization.

NFR-COMP-005 — CII registration + CERT-PK coordination [S]

Metric / Target. SITP shall be registered as Critical Information Infrastructure (CII) under Pakistan's framework; incident response shall follow a runbook aligned with CERT-PK notification expectations (initial notification within 24 h of a reportable incident). Measurement method. CII registration certificate on file; IR runbook reviewed annually; tabletop exercise annually. Rationale. Provincial government system handling citizen PII meets the national CII/CERT expectations.

NFR-COMP-006 — Procurement (PEPRA) alignment [S]

Metric / Target. The PPP engagement, vendor selection, source-code escrow, and exit/handover plan shall conform to Sindh Public-Private Partnership and PEPRA procurement norms; documentation auditable on demand. Measurement method. Procurement-file review at contract milestones; see /specs/en/23-ppp-vendor-exit/. Rationale. Procurement compliance protects the longevity and legitimacy of the engagement.

3.13 Auditability (AUD)

Auditability makes every state change and access reconstructable for the Auditor-General (AG), Public Accounts Committee (PAC), internal audit, and dispute resolution.

NFR-AUD-001 — Append-only audit for all state changes [M]

Metric / Target. Every state-changing action (ticket status, assignment, role/permission change, flag toggle, file access, integration call, AI call, login/step-up) shall write an immutable aud_event row containing who (user id + role), what (action + entity + before/after diff), when (UTC timestamp), why (business reason, where applicable), and trace_id. Measurement method. Per-endpoint audit-coverage test in CI; quarterly sample audit of reconstructability. Rationale. The four-W audit record is the universal currency of government accountability.

NFR-AUD-002 — Tamper-evidence [M]

Metric / Target. Audit rows shall be hash-chained (each row's hash incorporates the prior row's hash) so any tampering is detectable; quarterly verification confirms the chain; any break pages on-call. Measurement method. Hash-chain verification job; quarterly verification report; off-host copy retains chain. Rationale. Detectable tampering is the minimum bar for audit evidence to be admissible.

NFR-AUD-003 — Export for AG/PAC audit [M]

Metric / Target. The audit log shall be exportable (CSV/Excel/JSON) over a selectable date range and action filter, scoped to the requesting auditor's authority, with a signed manifest; exports are themselves audit-logged. Measurement method. Functional test of the export path per release; access-control test confirms scoping. Rationale. Auditors need extractable evidence in familiar formats.

NFR-AUD-004 — Access logging for confidential/VIP records [M]

Metric / Target. Every read of a Confidential or Restricted record (ticket, file, MoM) shall be audit-logged — not just writes — including the reader, the time, and the source IP; curious-reading alerts fire on abnormal patterns. Measurement method. Read-audit coverage test; quarterly access-pattern review. Rationale. Reads of sensitive records are as material as writes for privacy and trust-and-safety.

3.14 Interoperability (INTER)

SITP integrates with government systems and exposes APIs for partners. See /specs/en/08-integrations-spec/ and /specs/en/12-api-contract/.

NFR-INTER-001 — REST + JSON with OpenAPI [M]

Metric / Target. All public and inter-system APIs shall use REST + JSON with an OpenAPI 3.x contract; no SOAP, no proprietary binary protocol in V1; payloads versioned. Measurement method. OpenAPI generated and published per release (NFR-MAINT-004); contract test suite per endpoint. Rationale. REST+JSON+OpenAPI maximises the set of partners and tooling that can integrate.

NFR-INTER-002 — Webhook standard [S]

Metric / Target. SITP shall expose outbound webhooks for key domain events (ticket status change, MoM published, resolution) using a documented envelope (event type, timestamp, signature, payload); receivers verify an HMAC signature; retries per NFR-RELY-002. Measurement method. Webhook-contract test in CI; documented retry + signature scheme. Rationale. Webhooks are the standard event-delivery pattern for partner integrations.

NFR-INTER-003 — Adapter pattern for government integrations [M]

Metric / Target. Every government system (NADRA, SECP, FBR/SRB, PSEB, e-Office) shall be reached through an adapter behind a stable interface; the rest of the system shall never import a vendor SDK directly; adapters are independently testable with mocks. Measurement method. Architecture lint forbidding direct SDK import outside adapter modules (doc 15 §13); per-adapter mock test in CI. Rationale. Adapter isolation makes vendor change, sandbox testing, and on-prem fallback feasible.

NFR-INTER-004 — Versioned APIs + breaking-change policy [M]

Metric / Target. Public APIs shall be URI-versioned (/api/v1/...); breaking changes require a new major version with the prior version supported for ≥ 12 months; the OpenAPI spec-diff gates breaking changes behind explicit acknowledgement in CI. Measurement method. Spec-diff CI check; deprecation-notice review per release. Rationale. Partners and the mobile app depend on API stability; versioning + a deprecation policy are the contract.

NFR-INTER-005 — No vendor lock-in (multi-province replicability / multi-tenant) [S]

Metric / Target. The system shall be deployable, with configuration only, for another province or as a multi-tenant instance: tenant/organisation scoping in the schema, env-driven branding (per /specs/en/16-branding-design-system/), and no hard-coded "Sindh" string outside locale catalogs. Measurement method. Architecture review at Phase-3 gate; tenant-isolation test; string audit confirms no hard-coded province names. Rationale. Supports replicability across provinces and future SaaS-style operation; protects against vendor lock-in for the Government of Sindh.

3.15 Portability (PORT)

Portability protects the PPP exit/handover and the option to change hosting provider (Server4Sale → alternate).

NFR-PORT-001 — Containerized everything [M]

Metric / Target. Every application component (portal, API, WebSocket gateway, AI service, workers, Metabase, Keycloak) shall run in Docker containers with explicit resource limits and healthchecks; no host-installed application runtime. Measurement method. Per-release inventory confirms all components containerized; docker compose is the canonical local + staging + prod bring-up. Rationale. Containers are the precondition for portability and reproducible deploys.

NFR-PORT-002 — No hard environment coupling [M]

Metric / Target. No component shall hard-code the Server4Sale host, host paths, or host-specific config; all configuration via environment variables / config files mounted at runtime (12-factor); the system shall be deployable to an alternative provider with only configuration change. Measurement method. Configuration audit per release; quarterly "lift to alternate host" tabletop. Rationale. Vendor neutrality is a PPP safeguard (see /specs/en/23-ppp-vendor-exit/).

NFR-PORT-003 — Compose → Kubernetes graduation path [C]

Metric / Target. The Docker Compose topology shall be structured so each service definition maps cleanly to a future Kubernetes manifest (one Deploy per service, explicit healthchecks, resource requests/limits, secrets as env-from); no rewrite required to graduate. Measurement method. Architecture review at the scale-out trigger (per doc 15 §17, §22 item 3). Rationale. Preserves the documented scale-out option (doc 15 §17) without a future rewrite.

4. Summary Table

5. Targets Review Cadence

All targets in this document are V1 baselines. They are reviewed on the cadence below; revisions are recorded as a delta against this document with the previous value preserved in git history.

5.1 Phase-to-NFR mapping (indicative)

6. Open Items [TBD/confirm]

The following targets need confirmation by the named owner before the document is baselined:

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.