PPP Vendor & Exit Management

The contractual and operational framework that binds the operator (MAAHIR) and host (Server4Sale) to the S&ITD's mission for the Sindh IT Portal — Facilitation Desk (SITP): service levels, performance KPIs, milestone payments, source-code escrow, IP ownership, knowledge transfer, and a tested, executable exit/handover plan that guarantees continuity of service regardless of the operator.

1. Purpose & How to Read This Document

This document defines every binding safeguard that makes the SITP Public-Private Partnership (PPP) safe for the Government of Sindh. It exists for one reason: the platform must never become operator-dependent. The Science & Information Technology Department (S&ITD) owns the mission, the product, and the public interest; MAAHIR builds and operates it under a contract whose terms ensure that S&ITD can always take the platform back, hand it to a successor, or run it in-house — with no loss of service, data, or knowledge.

It is written to be RFP- and tender-ready and is the authoritative source for: the S&ITD program office, the MAAHIR delivery and operations leadership, the Server4Sale (host) account team, the source-code escrow agent, internal audit, and any future successor operator or in-house team. The five non-negotiable PPP safeguards named in _context.md §6 and /specs/en/14-roadmap-release/ §2.2 are detailed here:

1. Service-Level Agreements (SLAs) — availability, defect/severity response and resolution, support hours, and credits/penalties (§4).
2. Source-code escrow — deposit at every release; release to S&ITD on trigger events (§7).
3. Intellectual Property (IP) ownership — all deliverable IP vests in S&ITD (§8).
4. Knowledge transfer (KT) — per phase and before any transition (§10).
5. Exit / handover plan — a tested transition so continuity is never operator-dependent (§11).

These map to milestones M07–M11 in the milestone register (/specs/en/14-roadmap-release/ §7). Contract clauses in this document are numbered PPP-V-<nnn> (Vendor obligation) and are stable across the EN/UR/SD translations; they are referenced by ID from the contract, statement of work, and acceptance criteria.

2. PPP Model — Rationale & Structure

2.1 Why a PPP

A Public-Private Partnership gives S&ITD specialist speed and capability it cannot quickly build in-house — MAAHIR's product, AI, and trilingual engineering; Server4Sale's verified hosting — while retaining public ownership, accountability, and continuity through the binding safeguards in this document. The model matches the SIFC-style "single window" ambition: a private-operator cadence inside a government mandate. Pure in-house delivery would defer value by an estimated 12–18 months; pure outsourcing without safeguards would create operator lock-in and sovereignty risk (risk R6 in /specs/en/14-roadmap-release/ §12). The PPP with the safeguards below is the structure that resolves both.

2.2 Structure & ownership of the mission

S&ITD is the product owner and mission owner. MAAHIR is the operator under a build–operate–maintain contract. Server4Sale is the host under an approved sub-contract for infrastructure. The table below fixes who owns what.

2.3 What S&ITD always retains (incontestable)

Regardless of contract status, operator performance, or any dispute, S&ITD unconditionally retains: (a) the product and mission; (b) all deliverable IP (§8); (c) all production data and the database; (d) all credentials and access (revocable at will); (e) the domain, brand, and public identity; (f) the legal mandate and department MoUs; and (g) the right to invoke escrow, transition, and handover per this contract.

3. Contract Scope & Term

3.1 Scope — build, operate, maintain

The contract is a single integrated build + operate + maintain engagement covering the full V1 scope defined in _context.md §4 (modules A–Q) and delivered in phases per /specs/en/14-roadmap-release/. It is not a pure development contract followed by a separate maintenance contract; the operator is responsible for the platform's behaviour in production across the whole term, including: design, build, QA, release, managed services (L1/L2/L3), incident response, security operations, trilingual content maintenance, AI model upkeep, KB/SOP curation, analytics and reporting, and continuous improvement against the KPIs in §5.

3.2 Term, renewal, and termination triggers

The initial term spans the build phases plus a defined operate/maintain window aligned to the ADP budget cycle. Renewal is not automatic — it follows a formal performance review (§16). Termination may be:

• Termination for convenience by S&ITD (with notice and transition-period funding pre-negotiated so a handover is fundable without disruption, per /specs/en/14-roadmap-release/ §10.2).
• Termination for cause by S&ITD on any of the triggers below.
• Termination for insolvency of the operator (bankruptcy, winding-up, insolvency proceedings).
• Non-renewal at end of term, invoking the transition plan (§11).

Termination-for-cause triggers (PPP-V-101): (1) material and persistent SLA breach unremedied after the cure period (§4.4); (2) material security breach attributable to operator negligence (§13); (3) unauthorized subcontracting of core scope (§12); (4) IP or data misuse (§8, §9); (5) conviction or debarment under anti-corruption/PEPRA rules (§14); (6) abandonment or sustained inability to perform. On any termination trigger, the transition plan (§11) and escrow release (§7) activate immediately.

PPP-V-102 — No termination, however caused, ends the operator's obligation to hand over all code, data, credentials, and knowledge. The exit obligations in §§7–11 survive termination and contract expiry.

4. Vendor Service-Level Agreements (SLAs)

4.1 Availability

The platform shall meet NFR-AVAIL-001 — ≥ 99.9 % monthly uptime for the portal, API, and docs site (≈ 43 min/month or ≈ 8.7 h/year error budget), excluding planned maintenance per NFR-AVAIL-002 (/specs/en/03-non-functional-reqs/ §3.2). Availability is measured by the public status-page probes (NFR-OBS-005). Disaster-recovery objectives are RPO ≤ 1 h (NFR-AVAIL-004) and RTO ≤ 4 h (NFR-AVAIL-005). Graceful degradation (NFR-AVAIL-003) keeps the core ticket journey working when an AI/OCR or integration dependency is down.

4.2 Severity matrix — defects and incidents

All defects in production software and incidents affecting service are classified by severity. The matrix fixes acknowledgement, response, and resolution targets the operator must meet; it aligns the roadmap's Sev-1 patch target (≤ 72 h, /specs/en/14-roadmap-release/ §13.2) with the contract.

Support hours (PPP-V-201). P1 is supported 24×7 with a named on-call rotation and escalation to the MAAHIR delivery lead within 30 min. P2 is supported business hours (09:00–18:00 PKT, Mon–Sat) plus on-call. P3 is supported business hours. "Business hours" exclude Sindh public holidays and use the same holiday calendar as the SLA engine (_context.md §5).

4.3 Breach, credits, and penalties

A breach is missing an acknowledge/response/resolution target, or falling below the 99.9 % availability in a calendar month. Breaches accrue service credits (a deduction against the next invoice) and, when material or persistent, escalate to termination for cause (PPP-V-101).

Cure period (PPP-V-202). Before a non-security material breach becomes cause for termination, the operator receives a written cure notice and 30 calendar days to remedy (15 days for P1 availability), with a formal remediation plan reviewed weekly. Failure to cure within the period converts the breach into cause.

4.4 Planned maintenance and communication

Planned maintenance is excluded from the 99.9 % budget only when it (a) is scheduled in a low-traffic window per NFR-AVAIL-002, (b) is notified to S&ITD ≥ 72 h in advance, and (c) is published on the public status page. Emergency maintenance during business hours counts against availability. Every change follows release governance (/specs/en/14-roadmap-release/ §13.3) with rollback tested before release.

5. Vendor Performance KPIs

The operator's operational performance is measured continuously against the analytics plane in /specs/en/17-analytics-kpis/. The KPIs below are the vendor-scorecard subset: each has a target, a measurement source (the same anl_mv_* rollups that feed dashboards, so there is one definition per metric — AP-5), a review cadence, and a penalty/remedy linkage. Targets are configurable per anl_cfg_* and not hard-coded (AP-6).

One definition per metric. Because every vendor KPI is sourced from the same materialized views that feed the role dashboards, there is no separate "contract numbers" stream that can drift from operational reality. S&ITD and the operator always read the same numbers.

6. Milestone-Based Payments

Payment is milestone-based and gated, tied to the phase gates in /specs/en/14-roadmap-release/. No milestone payment is released until that milestone's exit criteria are met and signed off by the S&ITD product owner; each gated release also requires the concurrent PPP actions (escrow deposit M07, IP assignment note M08, KT note M09). The funding source is the dedicated ADP line (/specs/en/14-roadmap-release/ §10.2). Indicative payment structure (percentages are of the contracted build value; the operate/maintain window is fee-for-service on the cadence in §13 of the roadmap):

PPP-V-301 — Withholding. S&ITD may withhold any milestone payment until its gate criteria and the concurrent PPP actions are evidenced. Cure-then-invoice applies; payments withheld are not penalties and are released on cure.

7. Source-Code Escrow

Source-code escrow is the structural defence against operator lock-in (risk R6). It guarantees that, on a trigger event, S&ITD receives everything needed to build, deploy, operate, and secure the platform independently of MAAHIR. The escrow is established in Phase 0 (critical-path dependency C5, /specs/en/14-roadmap-release/ §8) and the first deposit is made at M03.

7.1 Escrow lifecycle

The lifecycle below describes the continuous deposit–verify–release loop that runs across every release for the life of the contract.

Written description. The escrow agent is appointed and the escrow agreement signed during Phase 0 (dependency C5), before any production code exists — this is deliberate, so the mechanism is in place before it could ever be needed. At every release (M03, M04, M05, M06, and every post-GA minor/patch release per the cadence in /specs/en/14-roadmap-release/ §13), the operator deposits the release's complete buildable materials (§7.2). The agent and S&ITD verify the deposit for completeness and buildability — a deposit that cannot be built is treated as not deposited. A receipt is recorded and the system returns to the ready state, awaiting the next release. If a trigger event (§7.3) occurs, the deposit moves to Released: the agent hands the materials to S&ITD, which can then run the platform independently (in-house, via a successor, or hybrid) per the transition plan (§11). The verify step is what makes escrow meaningful — unaudited escrow is a false safeguard.

7.2 What is escrowed

Every deposit must be a complete, buildable, operable snapshot. The "can a competent team rebuild and run this?" test is the acceptance bar; a partial deposit does not satisfy the milestone gate.

7.3 Release conditions (triggers)

The agent releases the escrow to S&ITD only on a contractually defined trigger, attested by S&ITD and (where disputed) confirmed by the dispute-resolution process (§15):

PPP-V-401 — No trigger required for the deposit obligation. The operator must deposit at every release regardless of relationship health. Escrow is a standing obligation, not a remedy invoked only at exit.

7.4 Escrow agent, verification, and costs

The agent is an independent third party (not an affiliate of MAAHIR or Server4Sale), selected via a transparent process (§14). The escrow agreement specifies: (a) the verification standard (buildability test on each deposit); (b) the release mechanics and attestation; (c) the retention period (deposits retained for the contract term + the agreed liability window); and (d) cost allocation — the operator bears the cost of deposit and verification as a cost of doing business; S&ITD bears the cost of any release process. Verification evidence (build log from the agent's attempt) is shared with S&ITD at each deposit and is a precondition of the milestone payment (§6).

8. Intellectual Property (IP) Ownership

8.1 Ownership — S&ITD owns all deliverable IP

PPP-V-501 — All intellectual property created, authored, developed, or customized for the SITP project vests in S&ITD, the Government of Sindh, from the moment of creation. This includes all source code, schemas, prompts, designs, the Ajrak-inspired brand, the documentation set, configuration, runbooks, models, and derivative works.

IP is not transferred at exit — it vests in S&ITD continuously. The assignment is recorded per release as part of milestone M08 (/specs/en/14-roadmap-release/ §7) so there is no IP ambiguity at any point. S&ITD owns:

8.2 Pre-existing tooling (vendor background IP)

The operator retains ownership of pre-existing, independently-developed tools, libraries, and frameworks that pre-date and are independent of this project ("Background IP"). However, any Background IP used in the deliverable must be: (a) disclosed in the third-party licence manifest (escrowed, §7.2); (b) licensed to the project on a perpetual, royalty-free, irrevocable, worldwide basis sufficient for S&ITD to operate, maintain, and modify the platform — including after termination; and (c) free of encumbrances that would prevent S&ITD's use. If a Background-IP component cannot be so licensed, it must not be used in the deliverable. This clause survives termination (PPP-V-102).

8.3 Assignment and moral rights

Each operator staff member and subcontractor who contributes to the deliverable executes an IP-assignment / work-for-hire clause as a condition of contributing, and waives moral rights to the extent permitted by law, so that S&ITD's title is unencumbered. The operator warrants that the deliverable infringes no third-party rights and indemnifies S&ITD against any IP infringement claim arising from the operator's work.

9. Data & Access on Exit

9.1 Data is S&ITD's; the operator is a custodian

All production data — ticket data, company and representative data, department data, audit logs, AI call records, analytics aggregates, uploads, MoM — belongs to S&ITD. The operator holds and processes it only as a custodian under the contract, the privacy obligations in /specs/en/03-non-functional-reqs/ §PRIV, and the security controls in /specs/en/11-security-compliance/. Sovereign data (CNIC, NADRA payloads) is handled under the data-sharing approvals and must never leave the approved boundary.

9.2 Handover of data on exit

PPP-V-601 — On exit (any termination or non-renewal), the operator must hand over ALL data in usable, documented form within the transition period (§11), at no additional charge, and must retain no copy.

The data handover comprises: (a) a full, consistent database export (MariaDB dump matching the released schema); (b) all object storage (MinIO buckets — uploads, generated letters, exports); (c) all logs and audit archives within the retention window; (d) analytics aggregates (anl_mv_*, anl_cube_*, anl_pub_*); (e) the configuration tables (anl_cfg_*, feature flags, RBAC, holiday calendar); and (f) any data held in operator-controlled SaaS (Mailjet, SMS/WA providers) within the operator's access. Delivery is to a destination S&ITD controls (the Server4Sale environment or a successor).

9.3 Credentials and access — revoked, secrets rotated

On exit: (a) all operator access is revoked — Keycloak accounts, SSH keys, deployment tokens, CI/CD secrets, cloud console access, vendor portal access (Mailjet/SMS/WA/OCR/LLM), database credentials, and any break-glass accounts; (b) all secrets are rotated — the escrow's secrets register (§7.2) lists every secret; live secret values are never escrowed and must be rotated at handover so the departing operator cannot use them; (c) a joint access-revocation log is signed off by both parties; (d) the operator confirms in writing that it retains no production credentials and no copy of production data, and deletes any local/dev copies under attestation. This satisfies the assume-breach principle (SEC control family, /specs/en/11-security-compliance/ §3) — at no point after exit can a former operator reach the platform.

10. Knowledge Transfer (KT)

Knowledge transfer is a per-phase and per-event obligation (milestone M09), not a single dump at the end. The goal is that, at any point, a competent team could take over the platform using the documentation, runbooks, and recorded walkthroughs left to date. KT is a precondition of each milestone payment (§6) and is tracked to closure.

PPP-V-701 — Training of the S&ITD team or a named replacement team is a paid, scheduled deliverable, not goodwill. A minimum number of KT hours per phase and a structured transition-KT plan during the transition period are specified in the statement of work. KT attendance and material delivery are evidenced and sign-off is a precondition of the milestone payment.

11. Transition & Exit Plan

11.1 Principle — continuity is never operator-dependent

The exit/handover plan is tested and executable, not theoretical. It is rehearsed (dry-run) before the readiness review (M10) so that S&ITD has evidence — not a promise — that it can take the platform over. The plan assumes the worst case (an involuntary exit under a termination-for-cause trigger) and must still guarantee continuity.

11.2 Reconstitution options

On exit, S&ITD reconstitutes operations through one of three options (or a hybrid), chosen based on the readiness review:

11.3 Transition period

A defined transition period (sized in the statement of work; indicative ≥ 90 days for a full operator change, shorter for a hybrid shift) precedes close-out. During it: (a) the current operator continues to operate the platform and supports the successor/in-house team; (b) KT (§10), data handover (§9), escrow release (§7.4 if triggered), and access rotation (§9.3) occur in sequence; (c) the successor runs the platform in shadow/parallel until S&ITD accepts the cutover; (d) continuity of service is maintained throughout — there is no scheduled outage for handover. Funding for the transition period is pre-negotiated (/specs/en/14-roadmap-release/ §10.2) so it is executable even under a termination for cause.

11.4 Exit/handover transition flow

Written description. An exit decision or trigger (notice, termination for cause, or bankruptcy/inability) starts the transition. For a voluntary or non-renewal exit, notice opens the transition period; for an involuntary exit, the escrow release is invoked immediately while access is preserved just long enough to execute the cutover. S&ITD then chooses a reconstitution option (in-house, new vendor via the §14 procurement process, or hybrid). All three paths feed a single transition workstream running across the transition period: knowledge transfer (§10), data handover (§9.2), access rotation and revocation (§9.3), escrow release and verification (§7.4), and a successor shadow/parallel run — all while the platform stays live. A readiness review (M10) gates the cutover: if not ready, the workstream continues; if ready, S&ITD accepts the cutover, the former operator's access is fully revoked, and close-out (M11) archives lessons learned. The end state is S&ITD operating independently — the single invariant of the entire PPP.

12. Subcontracting Control

12.1 No subcontracting of core scope without approval

PPP-V-801 — The operator must not subcontract any core scope of the contract without S&ITD's prior written approval. Unauthorized subcontracting of core scope is a termination-for-cause trigger (PPP-V-101).

"Core scope" includes: product/engineering leadership, application development (portal/API/AI), QA, security operations, and incident response. Approval considers the subcontractor's capability, security posture, and the safeguards in this document (the subcontractor is bound to the same SLAs, security, IP, data, and exit obligations as the operator, and S&ITD's rights flow through).

12.2 Server4Sale — approved hosting sub-contractor

Server4Sale is pre-approved as the hosting sub-contractor (the "Powered by Server4Sale" arrangement), and the hosting sub-contract is a named, accepted part of the PPP. Server4Sale's obligations include the availability/security standards in §4.1 and /specs/en/11-security-compliance/, backup and DR facility support, and cooperation with the exit plan (host access rotation, environment handover). Changes to the hosting arrangement (e.g., moving hosts) require S&ITD approval and must preserve the escrow, data-portability, and continuity safeguards.

13. Security Obligations

The operator's security obligations flow from the control catalogue in /specs/en/11-security-compliance/ and are contractually binding. The operator must implement, maintain, and evidence these controls for the life of the contract and during the transition period.

PPP-V-901 — Negligence-attributable security incidents carry no cure period. A confirmed incident caused by operator failure to maintain the controls above triggers an immediate service credit plus remediation at the operator's cost; a material such incident is cause for termination (PPP-V-101) and activates escrow release.

13.1 Breach notification timeline

A confirmed unauthorised access to or exfiltration of personal or sovereign data is a reportable incident: notify S&ITD within 1 hour of confirmation; notify CERT-PK within 24 h (SEC-092); notify affected individuals and the Sindh Information Commission where required. The operator cooperates fully with forensics and preserves evidence (SEC-093).

13.2 Personnel security

The operator maintains a current roster of all personnel with any access to the platform or its data, provided to S&ITD on request and on any change. Departing personnel access is revoked within 1 hour of departure and their secrets/devices returned; a confirmation is logged. The operator promptly removes any staff member S&ITD reasonably objects to on security/integrity grounds.

14. Conflict of Interest & Anti-Corruption

The procurement and operation of SITP align with the Sindh Public Procurement Regulatory Authority (PEPRA) framework and prevailing federal anti-corruption law. The operator and its staff must avoid any actual or apparent conflict of interest and must not offer, promise, give, or accept any improper advantage in connection with the contract.

• PEPRA alignment (PPP-V-1001). The operator's engagement, any successor procurement, and any subcontracting above thresholds follow PEPRA rules on transparency, competition, and record-keeping. This document is RFP/tender-ready (_context.md §9) so that any re-tender is open and fair.
• Disclosure. The operator discloses any conflict of interest (including relationships with S&ITD officials, competing bidders, or ecosystem partners) at signing and as they arise. S&ITD officials likewise declare interests.
• Transparency. Contract value, payment milestones, KPI performance, and any variations are recorded and available to internal audit and the Public Accounts Committee on request. The public transparency dashboard (doc 17 §11) publishes aggregate performance.
• Gifts & hospitality. A strict gifts-and-hospitality register is maintained; gifts beyond a nominal value are declined or declared.
• Whistleblowing. Reports of corruption or conflict may be made through the anonymous/whistleblower intake channel (/specs/en/24-trust-safety/); retaliation is prohibited.
• Consequences. Conviction, debarment, or a confirmed serious breach of this section is a termination-for-cause trigger (PPP-V-101).

15. Dispute Resolution

15.1 Governing law

The contract is governed by the laws of Pakistan, and specifically the law applicable to the Government of Sindh, including Sindh procurement and contract law. The courts of Karachi, Sindh have jurisdiction, subject to the arbitration clause below.

15.2 Resolution ladder

Disputes are resolved in stages to preserve the working relationship and continuity of service:

1. Operational resolution — the program office resolves day-to-day issues within the performance-review cadence (§16).
2. Negotiation — formal written notice; senior representatives of S&ITD and MAAHIR meet within 15 business days to resolve.
3. Mediation — a neutral mediator (agreed or appointed) attempts resolution within 30 business days.
4. Arbitration — unresolved disputes go to binding arbitration in Karachi under the Arbitration Act 1940 (as amended) / the Recognition and Enforcement (Arbitration Agreements and Foreign Arbitral Awards) Act 2011 framework, with a sole arbitrator (or three-member tribunal for material disputes) agreed by the parties or appointed per the rules.

PPP-V-1101 — Continuity during dispute. The operator must continue to operate the platform and meet SLAs during any dispute, and S&ITD must continue to pay undisputed invoices, until the dispute is resolved or the transition plan is invoked. A dispute never justifies service interruption. Escrow release and the transition plan (§11) remain available regardless of dispute status.

16. Performance Review Cadence

Performance against the SLAs (§4) and KPIs (§5) is reviewed on a fixed cadence by the joint S&ITD–MAAHIR program office, with escalation paths to S&ITD leadership.

17. Contract Change Management

Changes to scope, schedule, cost, or any SLA/KPI target are controlled so that the safeguards in this document are never silently eroded.

• Change request (CR). Any change is raised as a written CR with rationale, impact (scope/schedule/cost/risk), and affected clauses (including any SLA, KPI, escrow, IP, or exit clause).
• Impact assessment. The operator provides the impact assessment within 5 business days; S&ITD reviews for effect on the safeguards.
• Approval authority. Minor CRs are approved at the program-office level; material CRs (scope, cost beyond threshold, SLA/KPI target change, any change to §§7–11) require S&ITD executive approval and, where they affect public commitments, alignment with the public transparency dashboard.
• Safeguard protection. No change may weaken the escrow, IP ownership, data, or exit obligations (§§7–11) without explicit, recorded executive approval, and never so as to make the platform operator-dependent.
• Version control. The contract and this document are versioned; each release carries the applicable contract version. Variations are logged and auditable.

18. Insurance & Liability

19. Exit-Readiness Checklist

This checklist is the acceptance instrument for the readiness review (M10) and is rehearsed (dry-run) before any actual transition. A green checklist is the evidence — not the promise — that S&ITD can take the platform over. Status: ✓ required-pass; ◐ required-acceptable-with-plan.

20. References

20.1 Internal documentation

• Project context (locked decisions): ../_context.md
• Documentation conventions: ../_conventions.md
• Roadmap & release plan: /specs/en/14-roadmap-release/
• Non-functional requirements (availability, DR, privacy): /specs/en/03-non-functional-reqs/
• Security & compliance (controls, IR, breach notification): /specs/en/11-security-compliance/
• Analytics & KPIs (vendor scorecard sources): /specs/en/17-analytics-kpis/
• Tech architecture (escrow artefacts, DR topology): /specs/en/15-tech-architecture/
• Governance & legal (mandate, MoUs, RTI): /specs/en/22-governance-legal/
• Trust & safety (whistleblower channel): /specs/en/24-trust-safety/

20.2 External frameworks

• Sindh Public Procurement Regulatory Authority (PEPRA) — procurement transparency and competition.
• Sindh Transparency & Right to Information Act 2016 — statutory deadlines and disclosure.
• Pakistan Arbitration Act 1940 (as amended) and the Recognition and Enforcement (Arbitration Agreements and Foreign Arbitral Awards) Act 2011 — dispute resolution.
• CERT-PK — incident coordination and notification expectations.
• OWASP ASVS Level 2 — application security verification baseline.

End of document. Urdu and Sindhi parallel translations (ur.md, sd.md) follow this master structure exactly.