PPP وینڈر و ایگزٹ مینجمنٹ

وہ معاہداتی و آپریشنل فریم ورک جو آپریٹر (MAAHIR) اور ہوسٹ (Server4Sale) کو S&ITD کے سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) کے لیے مشن سے باندھتا ہے: سروس لیولز، کارکردگی KPIs، میل اسٹون ادائیگیاں، سورس کوڈ اسکرو، IP ملکیت، علم کی منتقلی، اور ایک جانچا ہوا، قابلِ عمل ایگزٹ/ہینڈ اوور پلان جو آپریٹر سے قطع نظر خدمت کے تسلسل کی ضمانت دیتا ہے۔

1. مقصد اور اس دستاویز کو پڑھنے کا طریقہ

یہ دستاویز ہر پابند تحفظ کو متعین کرتی ہے جو SITP پبلک پرائیویٹ پارٹنرشپ (PPP) کو سندھ حکومت کے لیے محفوظ بناتا ہے۔ یہ ایک وجہ سے موجود ہے: پلیٹ فارم کبھی آپریٹر پر منحصر نہیں بننا چاہیے۔ سائنس و انفارمیشن ٹیکنالوجی محکمہ (S&ITD) مشن، پروڈکٹ، اور عوامی مفاد کا مالک ہے؛ MAAHIR اسے ایک معاہدے کے تحت بناتا اور چلاتا ہے جس کی شرائط یہ یقینی بناتی ہیں کہ S&ITD ہمیشہ پلیٹ فارم واپس لے سکے، اسے کسی جانشین کے حوالے کر سکے، یا اندرونی طور پر چلا سکے — بغیر کسی خدمت، ڈیٹا، یا علم کے نقصان کے۔

اسے RFP اور ٹینڈر کے لیے تیار بنایا گیا ہے اور یہ ان کے لیے مستند ماخذ ہے: S&ITD پروگرام آفس، MAAHIR ترسیل و آپریشنز قیادت، Server4Sale (ہوسٹ) اکاؤنٹ ٹیم، سورس کوڈ اسکرو ایجنٹ، اندرونی آڈٹ، اور کسی بھی مستقبل کے جانشین آپریٹر یا اندرونی ٹیم۔ _context.md §6 اور /specs/ur/14-roadmap-release/ §2.2 میں نامزد پانچ غیر قابلِ مصالحہ PPP تحفظات یہاں تفصیل سے بیان کیے گئے ہیں:

1. سروس لیول ایگریمنٹس (SLAs) — دستیابی، نقص/شدت ردعمل و حل، معاونت کے اوقات، اور کریڈٹس/جرمانے (§4)۔
2. سورس کوڈ اسکرو — ہر ریلیز پر جمع؛ محرک واقعات پر S&ITD کو جاری (§7)۔
3. دانشہ صنعت (IP) ملکیت — تمام قابلِ ترسیل IP کا انتقال S&ITD کو ہوتا ہے (§8)۔
4. علم کی منتقلی (KT) — فی مرحلہ اور کسی بھی منتقلی سے پہلے (§10)۔
5. ایگزٹ / ہینڈ اوور پلان — ایک جانچی ہوئی منتقلی تاکہ تسلسل کبھی آپریٹر پر منحصر نہ رہے (§11)۔

یہ میل اسٹون رجسٹر (/specs/ur/14-roadmap-release/ §7) میں میل اسٹونز M07–M11 سے ملتے ہیں۔ اس دستاویز میں معاہدے کی شقیں PPP-V-<nnn> (وینڈر ذمہ داری) کے طور پر نمبر دی گئی ہیں اور EN/UR/SD تراجم میں مستحکم ہیں؛ انہیں معاہدے، ورک اسٹیٹمنٹ، اور قبولیت کے معیارات سے آئی ڈی کے ذریعے حوالہ دیا جاتا ہے۔

2. PPP ماڈل — وجہ اور ڈھانچہ

2.1 PPP کیوں

ایک پبلک پرائیویٹ پارٹنرشپ S&ITD کو وہ ماہرانہ رفتار اور صلاحیت فراہم کرتی ہے جو وہ جلدی اندرونی طور پر نہیں بنا سکتے — MAAHIR کی پروڈکٹ، AI، اور تین زبانی انجینئرنگ؛ Server4Sale کا تصدیق شدہ ہوسٹنگ — جبکہ اس دستاویز کے پابند تحفظات کے ذریعے عوامی ملکیت، جواب دہی، اور تسلسل برقرار رکھتی ہے۔ یہ ماڈل SIFC طرز کی "اکت واحد دریچہ" خواہش سے ہم آہنگ ہے: حکومتی مینڈیٹ کے اندر ایک نجی آپریٹر کی رفتار۔ خالص اندرونی ترسیل قدر کو تخمیناً 12–18 ماہ تک ملتوی کر دیتی؛ خالص آؤٹ سورسنگ بغیر تحفظات کے آپریٹر لاک-ان اور خودمختاری کا خطرہ پیدا کرتی (خطرہ R6 درج /specs/ur/14-roadmap-release/ §12 میں)۔ ذیل کے تحفظات کے ساتھ PPP وہ ڈھانچہ ہے جو دونوں کو حل کرتا ہے۔

2.2 مشن کا ڈھانچہ و ملکیت

S&ITD پروڈکٹ مالک اور مشن مالک ہے۔ MAAHIR ایک build–operate–maintain معاہدے کے تحت آپریٹر ہے۔ Server4Sale انفراسٹرکچر کے لیے ایک منظور شدہ ذیلی معاہدے کے تحت ہوسٹ ہے۔ ذیل کی میز طے کرتی ہے کہ کس کیا رکھتا ہے۔

2.3 جو S&ITD ہمیشہ رکھتا ہے (ناقابلِ تنازع)

معاہدے کی حیثیت، آپریٹر کی کارکردگی، یا کسی بھی تنازع سے قطع نظر، S&ITD بلامنازع یہ رکھتا ہے: (a) پروڈکٹ اور مشن؛ (b) تمام قابلِ ترسیل IP (§8)؛ (c) تمام پروڈکشن ڈیٹا اور ڈیٹا بیس؛ (d) تمام اسناد اور رسائی (مرضی کے مطابق قابلِ واپسی)؛ (e) ڈومین، برانڈ، اور عوامی شناخت؛ (f) قانونی مینڈیٹ اور محکمہ MoUs؛ اور (g) اس معاہدے کے مطابق اسکرو، منتقلی، اور ہینڈ اوور استعمال کرنے کا حق۔

3. معاہدے کا دائرہ کار و مدت

3.1 دائرہ کار — تعمیر، چلانا، دیکھ بھال

معاہدہ ایک واحد مربوط build + operate + maintain معاہدہ ہے جو _context.md §4 میں متعین مکمل V1 دائرہ کار (ماڈیولز A–Q) پر محیط ہے اور /specs/ur/14-roadmap-release/ کے مطابق مرحلوں میں ترسیل کیا جاتا ہے۔ یہ ایک خالص ڈویلپمنٹ معاہدہ نہیں جس کے بعد الگ دیکھ بھال کا معاہدہ ہو؛ آپریٹر پوری مدت کے دوران پروڈکشن میں پلیٹ فارم کے رویے کا ذمہ دار ہے، بشمول: ڈیزائن، تعمیر، QA، ریلیز، منیجڈ سروسز (L1/L2/L3)، واقعات کا ردعمل، سیکیورٹی آپریشنز، تین زبانی مواد کی دیکھ بھال، AI ماڈل کی نگہداشت، KB/SOP کی تدوین، تجزیات و رپورٹنگ، اور §5 کے KPIs کے خلاف مسلسل بہتری۔

3.2 مدت، تجدید، اور خاتمے کے محرکات

ابتدائی مدت تعمیر کے مراحل کے ساتھ ساتھ ADP بجٹ سائیکل سے ہم آہنگ ایک متعین operate/maintain دریچے پر محیط ہے۔ تجدید خودکار نہیں — یہ ایک باقاعدہ کارکردگی جائزہ (§16) کے بعد ہوتی ہے۔ خاتمہ درج ذیل میں سے کوئی ہو سکتا ہے:

• سہولت کے لیے خاتمہ S&ITD کی طرف سے (نوٹس کے ساتھ اور منتقلی کے دوران کی مالیہ پہلے سے طے شدہ تاکہ ہینڈ اوور بغیر رکاوٹ کے مالیہ یافتہ ہو سکے، /specs/ur/14-roadmap-release/ §10.2 کے مطابق)۔
• وجہ کی بناء پر خاتمہ S&ITD کی طرف سے ذیل کے کسی بھی محرک پر۔
• دیوالیہ پن کی بناء پر خاتمہ آپریٹر کا (bankruptcy، winding-up، دیوالیہ پن کے کارروائیاں)۔
• مدت کے اختتام پر عدمِ تجدید، منتقلی پلان (§11) کو چالو کرتے ہوئے۔

وجہ کی بناء پر خاتمے کے محرکات (PPP-V-101): (1) علاج کی مدت کے بعد بھی دورanst اور مسلسل SLA خلاف ورزی جو دور نہ ہو (§4.4)؛ (2) آپریٹر کی غفلت کی وجہ سے اہم سیکیورٹی خلاف ورزی (§13)؛ (3) بنیادی دائرہ کار کا غیر مجاز ذیلی کنٹراكٹنگ (§12)؛ (4) IP یا ڈیٹا کا غلط استعمال (§8، §9)؛ (5) مخالفِ بدعنوانی/PEPRA قواعد کے تحت سزا یا نااہلی (§14)؛ (6) ترک یا مسلسل عدمِ اہلیت۔ کسی بھی خاتمے کے محرک پر، منتقلی پلان (§11) اور اسکرو جاری (§7) فوراً چالو ہو جاتے ہیں۔

PPP-V-102 — کوئی بھی خاتمہ، خواہ کسی بھی وجہ سے ہو، آپریٹر کی تمام کوڈ، ڈیٹا، اسناد، اور علم کے حوالے کرنے کی ذمہ داری ختم نہیں کرتا۔ §§7–11 میں ایگزٹ ذمہ داریاں خاتمے اور معاہدے کی میعاد پوری ہونے کے بعد بھی باقی رہتی ہیں۔

4. وینڈر سروس لیول ایگریمنٹس (SLAs)

4.1 دستیابی

پلیٹ فارم NFR-AVAIL-001 — ماہانہ ≥ 99.9 % اپ ٹائم کا معیار پورا کرے گا — پورٹل، API، اور docs سائٹ کے لیے (تقریباً 43 منٹ/ماہ یا تقریباً 8.7 گھنٹے/سال ایرر بجٹ)، NFR-AVAIL-002 کے مطابق منصوبہ بند دیکھ بھال کے علاوہ (/specs/ur/03-non-functional-reqs/ §3.2)۔ دستیابی عوامی اسٹیٹس پیج پروبس (NFR-OBS-005) سے ناپی جاتی ہے۔ ڈیزاسٹر ری کوری اہداف RPO ≤ 1 گھنٹہ (NFR-AVAIL-004) اور RTO ≤ 4 گھنٹے (NFR-AVAIL-005) ہیں۔ مناسب تنزل (NFR-AVAIL-003) اس وقت کور ٹکٹ سفر کو کام کرتے رکھتا ہے جب AI/OCR یا انضمام کا انحصار ڈاؤن ہو۔

4.2 شدت میٹرکس — نقصات اور واقعات

پروڈکشن سافٹ ویئر کے تمام نقصات اور خدمت کو متاثر کرنے والے واقعات کو شدت کے مطابق درجہ بندی کیا جاتا ہے۔ میٹرکس ردعمل، جواب، اور حل کے اہداف طے کرتا ہے جو آپریٹر کو پورے کرنے ہوتے ہیں؛ یہ روڈ میپ کے Sev-1 پیچ ٹارگٹ (≤ 72 گھنٹے، /specs/ur/14-roadmap-release/ §13.2) کو معاہدے سے ہم آہنگ کرتا ہے۔

معاونت اوقات (PPP-V-201)۔ P1 کی معاونت 24×7 نامزد آن کال روٹیشن کے ساتھ اور 30 منٹ کے اندر MAAHIR ترسیل لیڈ تک اسکیلیشن کے ساتھ ہے۔ P2 کی معاونت کاروباری اوقات (09:00–18:00 PKT، پیر–ہفتہ) plus آن کال ہے۔ P3 کی معاونت کاروباری اوقات میں ہے۔ "کاروباری اوقات" سندھ کی عوامی چھٹیوں کو خارج کرتے ہیں اور SLA انجن (_context.md §5) کے ہی ہالیڈے کیلنڈر کا استعمال کرتے ہیں۔

4.3 خلاف ورزی، کریڈٹس، اور جرمانے

ایک خلاف ورزی اس وقت ہوتی ہے جب ردعمل/جواب/حل کا ہدف نہ پورا ہو، یا کسی کیلنڈر ماہ میں 99.9 % دستیابی سے نیچے گر جائے۔ خلاف ورزیاں سروس کریڈٹس (اگلے انوائس میں کٹوتی) جمع کرتی ہیں اور، جب اہم یا مسلسل ہوں، تو وجہ کی بناء پر خاتمے (PPP-V-101) تک بڑھ جاتی ہیں۔

علاج کی مدت (PPP-V-202)۔ اس سے پہلے کہ ایک غیر سیکیورٹی اہم خلاف ورزی خاتمے کی وجہ بنے، آپریٹر کو ایک تحریری علاج نوٹس اور درست کرنے کے لیے 30 کیلنڈر دن ملتے ہیں (P1 دستیابی کے لیے 15 دن)، جس میں ایک باقاعدہ اصلاحی پلان ہفتہ وار جائزہ لیا جاتا ہے۔ مدت کے اندر علاج نہ کرنا خلاف ورزی کو وجہ میں تبدیل کر دیتا ہے۔

4.4 منصوبہ بند دیکھ بھال اور مواصلات

منصوبہ بند دیکھ بھال تب ہی 99.9 % بجٹ سے خارج کی جاتی ہے جب وہ (a) NFR-AVAIL-002 کے مطابق کم ٹریفک دریچے میں شیڈول ہو، (b) S&ITD کو ≥ 72 گھنٹے پہلے مطلع کیا گیا ہو، اور (c) عوامی اسٹیٹس پیج پر شائع کیا گیا ہو۔ کاروباری اوقات میں ایمرجنسی دیکھ بھال دستیابی کے خلاف شمار ہوتی ہے۔ ہر تبدیپی ریلیز گورننس (/specs/ur/14-roadmap-release/ §13.3) کی پیروی کرتی ہے جس میں ریلیز سے پہلے rollback جانچا جاتا ہے۔

5. وینڈر کارکردگی KPIs

آپریٹر کی آپریشنل کارکردگی مسلسل /specs/ur/17-analytics-kpis/ میں تجزیاتی پلین کے خلاف ناپی جاتی ہے۔ ذیل کے KPIs وینڈر اسکور کارڈ سب سیٹ ہیں: ہر ایک کا ہدف، پیمائش کا ماخذ (وہی anl_mv_* رول اپس جو ڈیش بورڈز کو فیڈ کرتے ہیں، تاکہ ہر میٹرک کے لیے ایک تعریف ہو — AP-5)، جائزہ کیڈنس، اور جرمانہ/علاج ربط ہے۔ اہداف anl_cfg_* کے مطابق قابلِ ترتیب ہیں اور ہارڈ کوڈڈ نہیں (AP-6)۔

فی میٹرک ایک تعریف۔ چونکہ ہر وینڈر KPI اسی میٹریلائزڈ ویوز سے ماخوذ ہے جو کردار ڈیش بورڈز کو فیڈ کرتے ہیں، اس لیے کوئی الگ "معاہدہ نمبرز" سلسلہ نہیں جو آپریشنل حقیقت سے ہٹ کر چل سکے۔ S&ITD اور آپریٹر ہمیشہ ایک ہی نمبرز پڑھتے ہیں۔

6. میل اسٹون پر مبنی ادائیگیاں

ادائیگی میل اسٹون پر مبنی اور گیٹڈ ہے، جو /specs/ur/14-roadmap-release/ میں فیز گیٹس سے جڑی ہے۔ کسی بھی میل اسٹون ادائیگی اس وقت تک جاری نہیں ہوتی جب تک کہ اس میل اسٹون کے ایگزٹ معیارات پورے نہ ہوں اور S&ITD پروڈکٹ مالک کے دستخط نہ ہوں؛ ہر گیٹڈ ریلیز کے لیے ساتھ PPP کارروائیاں (اسکرو جمع M07، IP اسائنمنٹ نوٹ M08، KT نوٹ M09) بھی ضروری ہیں۔ مالیہ کا ماخص مخصوص ADP لائن ہے (/specs/ur/14-roadmap-release/ §10.2)۔ اشاری ادائیگی ڈھانچہ (فیصدیں معاہدے کی تعمیری قیمت کی ہیں؛ operate/maintain دریچہ روڈ میپ کے §13 کے کیڈنس پر فیس فار سروس ہے):

PPP-V-301 — روکنا۔ S&ITD اپنے گیٹ معیارات اور ساتھ PPP کارروائیوں کے ثبوت تک کسی بھی میل اسٹون ادائیگی کو روک سکتا ہے۔ علاج پھر انوائس لاگو ہوتا ہے؛ روکی گئی ادائیگیاں جرمانے نہیں اور علاج پر جاری ہوتی ہیں۔

7. سورس کوڈ اسکرو

سورس کوڈ اسکرو آپریٹر لاک-ان (خطرہ R6) کے خلاف ڈھانچے کا دفاع ہے۔ یہ ضمانت دیتا ہے کہ، محرک واقعے پر، S&ITD کو MAAHIR سے آزادانہ طور پر پلیٹ فارم بنانے، تعین کرنے، چلانے، اور محفوظ کرنے کے لیے ہر ضروری چیز ملتی ہے۔ اسکرو Phase 0 میں قائم کیا جاتا ہے (تنقیدی راستے کی انحصاری C5، /specs/ur/14-roadmap-release/ §8) اور پہلی جمع M03 پر کی جاتی ہے۔

7.1 اسکرو لائف سائکل

ذیل کا لائف سائکل اس مسلسل جمع—تصدیق—جاری لوپ کو بیان کرتا ہے جو معاہدے کی زندگی بھر ہر ریلیز کے لیے چلتا ہے۔

تحریری وضاحت۔ اسکرو ایجنٹ مقرر اور اسکرو ایگریمنٹ Phase 0 (انحصاری C5) کے دوران، کسی بھی پروڈکشن کوڈ کے وجود سے پہلے دستخط کیا جاتا ہے — یہ جان بوجھ کر ہے، تاکہ یہ نظام اس سے پہلے قائم ہو جائے کہ اس کی ضرورت پڑے۔ ہر ریلیز پر (M03، M04، M05، M06، اور /specs/ur/14-roadmap-release/ §13 کے کیڈنس کے مطابق ہر پوسٹ-GA مائنر/پیچ ریلیز)، آپریٹر اس ریلیز کا مکمل قابلِ تعمیر مواد (§7.2) جمع کرتا ہے۔ ایجنٹ اور S&ITD جمع کرائی کی تکمیل اور قابلِ تعمیر ہونے کی تصدیق کرتے ہیں — ایسی جمع جو تعمیر نہ ہو سکے اسے جمع نہ ہونا سمجھا جاتا ہے۔ ایک رسید ریکارڈ کی جاتی ہے اور نظام تیار حالت میں واپس آ جاتا ہے، اگلی ریلیز کا منتظر۔ اگر کوئی محرک واقعہ (§7.3) ہو، تو جمع Released کی طرف بڑھ جاتی ہے: ایجنٹ مواد S&ITD کے حوالے کرتا ہے، جو پھر منتقلی پلان (§11) کے مطابق پلیٹ فارم آزادانہ طور پر (اندرونی، جانشین کے ذریعے، یا ہائبرڈ) چلا سکتا ہے۔ تصدیق کا قدم ہی اسکرو کو معنی دار بناتا ہے — غیر جانچا ہوا اسکرو ایک جھوٹا تحفظ ہے۔

7.2 کیا اسکرو کیا جاتا ہے

ہر جمع ایک مکمل، قابلِ تعمیر، قابلِ عمل snapshot ہونی چاہیے۔ "کیا کوئی اہل ٹیم اسے دوبارہ بنا اور چلا سکتی ہے؟" کا ٹیسٹ قبولیت کا معیار ہے؛ نامکمل جمع میل اسٹون گیٹ کو پورا نہیں کرتی۔

7.3 جاری کرنے کی شرائط (محرکات)

ایجنٹ اسکرو S&ITD کو صرف معاہداتی طور پر متعین محرک پر جاری کرتا ہے، جس کی S&ITD تصدیق ہو اور (جہاں متنازع ہو) تنازع حل کے عمل (§15) سے تصدیق ہو:

PPP-V-401 — جمع کی ذمہ داری کے لیے کوئی محرک درکار نہیں۔ آپریٹر کو تعلقات کی صحت سے قطع نظر ہر ریلیز پر جمع کرنا ہے۔ اسکرو ایک مستحکم ذمہ داری ہے، صرف ایگزٹ پر استعمال ہونے والا علاج نہیں۔

7.4 اسکرو ایجنٹ، تصدیق، اور لاگتیں

ایجنٹ ایک آزاد تیسرا فریق ہے (MAAHIR یا Server4Sale کا affiliate نہیں)، ایک شفاف عمل (§14) کے ذریعے منتخب کیا گیا۔ اسکرو ایگریمنٹ متعین کرتا ہے: (a) تصدیقی معیار (ہر جمع پر قابلِ تعمیر ٹیسٹ)؛ (b) جاری کرنے کا طریقہ کار اور تصدیق؛ (c) retention مدت (جمع معاہدے کی مدت + متفقہ ذمہ داری دریچے کے لیے برقرار رکھی جاتی ہیں)؛ اور (d) لاگت کی تقسیم — آپریٹر جمع اور تصدیق کی لاگت اٹھاتا ہے بطورِ کاروبار کی لاگت؛ S&ITD کسی بھی جاری عمل کی لاگت اٹھاتا ہے۔ تصدیقی ثبوت (ایجنٹ کی کوشش سے build log) ہر جمع پر S&ITD کے ساتھ شیئر کیا جاتا ہے اور میل اسٹون ادائیگی (§6) کی پیش شرط ہے۔

8. دانشہ صنعت (IP) ملکیت

8.1 ملکیت — S&ITD تمام قابلِ ترسیل IP کا مالک ہے

PPP-V-501 — SITP منصوبے کے لیے بنائی، تحریر کردہ، تیار کردہ، یا مخصوص کردہ تمام دانشہ صنعت، پیداوار کے لمحے سے، سندھ حکومت یعنی S&ITD میں منتقل ہو جاتی ہے۔ اس میں تمام سورس کوڈ، schemas، prompts، ڈیزائنز، Ajrak سے متاثر برانڈ، دستاویزی سیٹ، config، runbooks، ماڈلز، اور مشتق کام شامل ہیں۔

IP ایگزٹ پر منتقل نہیں ہوتی — یہ مسلسل S&ITD میں رہتی ہے۔ اسائنمنٹ میل اسٹون M08 (/specs/ur/14-roadmap-release/ §7) کے حصے کے طور پر فی ریلیز ریکارڈ کیا جاتا ہے تاکہ کسی بھی وقت IP کی ابہام نہ رہے۔ S&ITD رکھتا ہے:

8.2 منصوبے سے پہلے کا ٹولنگ (وینڈر بیک گراؤنڈ IP)

آپریٹر ان پہلے سے موجود، آزادانہ طور پر تیار کردہ ٹولز، لائبریریوں، اور فریم ورکس کی ملکیت برقرار رکھتا ہے جو اس منصوبے سے پہلے کے اور اس سے آزاد ہیں ("Background IP")۔ تاہم، قابلِ ترسیل میں استعمال ہونے والی کوئی بھی Background IP ہونی چاہیے: (a) تیسرے فریق کے licence manifest میں ظاہر (اسکرو، §7.2)؛ (b) منصوبے کو ہمیشہ کے لیے، royalty-free، ناقابلِ واپسی، دنیا بھر کی بنیاد پر لائسنس یافتہ — کافی تاکہ S&ITD پلیٹ فارم چلا سکے، دیکھ بھال کر سکے، اور تبدیل کر سکے — بشمول خاتمے کے بعد؛ اور (c) ایسی رکاوٹوں سے پاک جو S&ITD کے استعمال کو روکیں۔ اگر کوئی Background-IP جزو ایسے لائسنس نہ ہو سکے، تو اسے قابلِ ترسیل میں استعمال نہیں کرنا چاہیے۔ یہ شق خاتمے کے بعد باقی رہتی ہے (PPP-V-102)۔

8.3 اسائنمنٹ اور moral rights

ہر وہ آپریٹر عملہ اور ذیلی کنٹریکٹر جو قابلِ ترسیل میں حصہ ڈالتا ہے، حصہ ڈالنے کی شرط کے طور پر ایک IP اسائنمنٹ / work-for-hire شق پر عمل کرتا ہے، اور قانون کی اجازت کی حد تک moral rights سے دستبردار ہوتا ہے، تاکہ S&ITD کا عنوان بے رکاوٹ ہو۔ آپریٹر ضمانت دیتا ہے کہ قابلِ ترسیل کسی تیسرے فریق کے حقوق کی خلاف ورزی نہیں کرتی اور آپریٹر کے کام سے پیدا ہونے والے کسی بھی IP خلاف ورزی دعوے کے خلاف S&ITD کو ہرجانہ دیتا ہے۔

9. ایگزٹ پر ڈیٹا و رسائی

9.1 ڈیٹا S&ITD کا ہے؛ آپریٹر محافظ ہے

تمام پروڈکشن ڈیٹا — ٹکٹ ڈیٹا، کمپنی اور نمائندہ ڈیٹا، محکمہ ڈیٹا، آڈٹ لاگز، AI کال ریکارڈز، تجزیاتی مجموعے، uploads، MoM — S&ITD کا ہے۔ آپریٹر اسے صرف معاہدے کے تحت، /specs/ur/03-non-functional-reqs/ §PRIV کی پرائیویسی ذمہ داریوں، اور /specs/ur/11-security-compliance/ کے سیکیورٹی کنٹرولز کے تحت محافظ کے طور پر رکھتا اور پروسیس کرتا ہے۔ خودمختار ڈیٹا (CNIC، NADRA payloads) ڈیٹا اشتراکی منظوریوں کے تحت سنبھالا جاتا ہے اور منظور شدہ حد سے باہر کبھی نہیں نکلتا۔

9.2 ایگزٹ پر ڈیٹا کا ہینڈ اوور

PPP-V-601 — ایگزٹ پر (کوئی بھی خاتمہ یا عدمِ تجدید)، آپریٹر کو منتقلی مدت (§11) کے اندر تمام ڈیٹا قابلِ استعمال، دستاویزی شکل میں، بغیر اضافی چارج کے حوالے کرنا ہے، اور اس کی کوئی کاپی برقرار نہیں رکھنی۔

ڈیٹا ہینڈ اوور پر مشتمل ہے: (a) ایک مکمل، مستقل ڈیٹا بیس ایکسپورٹ (جاری schema سے مماثل MariaDB dump)؛ (b) تمام object storage (MinIO buckets — uploads، تیار کردہ خطوط، exports)؛ (c) retention دریچے کے اندر تمام لاگز اور آڈٹ آرکائیوز؛ (d) تجزیاتی مجموعے (anl_mv_*، anl_cube_*، anl_pub_*)؛ (e) config ٹیبلز (anl_cfg_*، feature flags، RBAC، ہالیڈے کیلنڈر)؛ اور (f) آپریٹر کی رسائی کے اندر آپریٹر کنٹرولڈ SaaS (Mailjet، SMS/WA فراہم کرنے والے) میں رکھا گیا کوئی بھی ڈیٹا۔ ترسیل ایسے منزل کو ہوتی ہے جسے S&ITD کنٹرول کرتا ہے (Server4Sale ماحول یا جانشین)۔

9.3 اسناد اور رسائی — منسوخ، secrets rotate

ایگزٹ پر: (a) تمام آپریٹر رسائی منسوخ — Keycloak اکاؤنٹس، SSH keys، deployment tokens، CI/CD secrets، کلاؤڈ کنسول رسائی، وینڈر پورٹل رسائی (Mailjet/SMS/WA/OCR/LLM)، ڈیٹا بیس اسناد، اور کوئی بھی break-glass اکاؤنٹس؛ (b) تمام secrets rotate — اسکرو کا secrets رجسٹر (§7.2) ہر secret کو فہرست کرتا ہے؛ لائیو secret قدریں کبھی اسکرو نہیں کی جاتیں اور ہینڈ اوور پر rotate ہونی چاہئیں تاکہ روانہ آپریٹر انہیں استعمال نہ کر سکے؛ (c) ایک مشترکہ رسائی منسوخی لاگ دونوں فریقوں کے دستخط شدہ ہو؛ (d) آپریٹر تحریری طور پر تصدیق کرے کہ اس کے پاس کوئی پروڈکشن اسناد اور کوئی پروڈکشن ڈیٹا کاپی نہیں، اور تصدیق کے تحت کسی بھی local/dev کاپیاں حذف کر دے۔ یہ assume-breach اصول (SEC کنٹرول فیملی، /specs/ur/11-security-compliance/ §3) کو پورا کرتا ہے — ایگزٹ کے بعد کسی بھی وقت سابقہ آپریٹر پلیٹ فارم تک نہیں پہنچ سکتا۔

10. علم کی منتقلی (KT)

علم کی منتقلی ایک فی مرحلہ اور فی واقعہ ذمہ داری ہے (میل اسٹون M09)، اختتام پر ایک واحد dump نہیں۔ مقصد یہ ہے کہ کسی بھی وقت ایک اہل ٹیم اب تک کی دستاویزات، runbooks، اور ریکارڈ کردہ walkthroughs کا استعمال کرتے ہوئے پلیٹ فارم سنبھال سکے۔ KT ہر میل اسٹون ادائیگی (§6) کی پیش شرط ہے اور اختتام تک ٹریک کی جاتی ہے۔

PPP-V-701 — S&ITD ٹیم یا نامزد متبادل ٹیم کی تربیت ایک معاوضہ یافتہ، شیڈول کردہ ترسیل ہے، خیر خواہی نہیں۔ ورک اسٹیٹمنٹ میں فی مرحلہ KT گھنٹوں کی کم سے کم تعداد اور منتقلی مدت کے دوران ایک منظم transition-KT پلان متعین ہے۔ KT شرکت اور مواد کی ترسیل کے ثبوت ہوتے ہیں اور دستخط میل اسٹون ادائیگی کی پیش شرط ہے۔

11. منتقلی و ایگزٹ پلان

11.1 اصول — تسلسل کبھی آپریٹر پر منحصر نہیں

ایگزٹ/ہینڈ اوور پلان جانچا ہوا اور قابلِ عمل ہے، نظریاتی نہیں۔ یہ تیاری جائزے (M10) سے پہلے مشق (ڈرائی رن) کیا جاتا ہے تاکہ S&ITD کے پاس ثبوت ہو — وعدہ نہیں — کہ وہ پلیٹ فارم سنبھال سکتا ہے۔ پلان بدترین صورت (وجہ کی بناء پر خاتمے کے محرک کے تحت غیر ارادی ایگزٹ) فرض کرتا ہے اور پھر بھی تسلسل کی ضمانت دینا چاہیے۔

11.2 دوبارہ ترتیب کے اختیارات

ایگزٹ پر، S&ITD تین اختیارات میں سے ایک (یا ہائبرڈ) کے ذریعے آپریشنز دوبارہ ترتیب دیتا ہے، جو تیاری جائزے کی بنیاد پر منتخب کیا جاتا ہے:

11.3 منتقلی مدت

ایک متعین منتقلی مدت (سائز ورک اسٹیٹمنٹ میں؛ مکمل آپریٹر تبدیلی کے لیے اشاری ≥ 90 دن، ہائبرڈ تبدیلی کے لیے مختصر) اختتامیے سے پہلے آتی ہے۔ اس کے دوران: (a) موجودہ آپریٹر پلیٹ فارم چلاتا رہتا ہے اور جانشین/اندرونی ٹیم کی معاونت کرتا ہے؛ (b) KT (§10)، ڈیٹا ہینڈ اوور (§9)، اسکرو جاری (§7.4 اگر محرک ہو)، اور رسائی rotation (§9.3) ترتیب سے ہوتے ہیں؛ (c) جانشین پلیٹ فارم کو shadow/parallel چلاتا ہے یہاں تک کہ S&ITD cutover قبول کر لے؛ (d) تسلسلِ خدمت مکمل برقرار رہتا ہے — ہینڈ اوور کے لیے کوئی شیڈولڈ بندش نہیں۔ منتقلی مدت کا مالیہ پہلے طے شدہ ہے (/specs/ur/14-roadmap-release/ §10.2) تاکہ یہ وجہ کی بناء پر خاتمے کے تحت بھی قابلِ عمل ہو۔

11.4 ایگزٹ/ہینڈ اوور منتقلی بہاؤ

تحریری وضاحت۔ ایک ایگزٹ فیصلہ یا محرک (نوٹس، وجہ کی بناء پر خاتمہ، یا دیوالیہ پن/عدمِ اہلیت) منتقلی شروع کرتا ہے۔ رضاکارانہ یا عدمِ تجدید ایگزٹ کے لیے، نوٹس منتقلی مدت کھولتا ہے؛ غیر ارادی ایگزٹ کے لیے، اسکرو جاری فوراً استعمال ہوتا ہے جبکہ رسائی صرف cutover پر عمل درآمد کے لیے برقرار رکھی جاتی ہے۔ S&ITD پھر ایک دوبارہ ترتیب اختیار (اندرونی، §14 procurement عمل کے ذریعے نیا وینڈر، یا ہائبرڈ) منتخب کرتا ہے۔ تینوں راستے ایک واحد منتقلی ورک سٹریم کو فیڈ کرتے ہیں جو منتقلی مدت بھر چلتی ہے: علم کی منتقلی (§10)، ڈیٹا ہینڈ اوور (§9.2)، رسائی rotation اور منسوخی (§9.3)، اسکرو جاری اور تصدیق (§7.4)، اور جانشین shadow/parallel رن — سب کے دوران پلیٹ فارم لائیو رہتا ہے۔ ایک تیاری جائزہ (M10) cutover کو گیٹ کرتا ہے: اگر تیار نہ ہو تو ورک سٹریم جاری رہتی ہے؛ اگر تیار ہو تو S&ITD cutover قبول کرتا ہے، سابقہ آپریٹر کی رسائی مکمل منسوخ ہوتی ہے، اور اختتامیہ (M11) سبق حاصل آرکائیو کرتا ہے۔ آخری حالت S&ITD کا آزادانہ طور پر چلنا ہے — پوری PPP کا واحد اٹل۔

12. ذیلی کنٹراكٹنگ کنٹرول

12.1 S&ITD کی پیشگی تحریری منظوری کے بغیر بنیادی دائرہ کار کا کوئی ذیلی کنٹراكٹنگ نہیں

PPP-V-801 — آپریٹر کو S&ITD کی پیشگی تحریری منظوری کے بغیر معاہدے کے کسی بنیادی دائرہ کار کا ذیلی کنٹراكٹنگ نہیں کرنا چاہیے۔ بنیادی دائرہ کار کا غیر مجاز ذیلی کنٹراكٹنگ ایک وجہ کی بناء پر خاتمے کا محرک ہے (PPP-V-101)۔

"بنیادی دائرہ کار" میں شامل ہیں: پروڈکٹ/انجینئرنگ قیادت، ایپلیکیشن ڈویلپمنٹ (پورٹل/API/AI)، QA، سیکیورٹی آپریشنز، اور واقعات کا ردعمل۔ منظوری ذیلی کنٹریکٹر کی صلاحیت، سیکیورٹی حالت، اور اس دستاویز کے تحفظات پر غور کرتی ہے (ذیلی کنٹریکٹر وہی SLAs، سیکیورٹی، IP، ڈیٹا، اور ایگزٹ ذمہ داریوں کا پابند ہے جو آپریٹر، اور S&ITD کے حقوق ان تک پہنچتے ہیں)۔

12.2 Server4Sale — منظور شدہ ہوسٹنگ ذیلی کنٹریکٹر

Server4Sale ہوسٹنگ ذیلی کنٹریکٹر کے طور پر پہلے سے منظور شدہ ہے ("Powered by Server4Sale" انتظام)، اور ہوسٹنگ ذیلی معاہدہ PPP کا نامزد، قبول شدہ حصہ ہے۔ Server4Sale کی ذمہ داریوں میں §4.1 اور /specs/ur/11-security-compliance/ کے دستیابی/سیکیورٹی معیارات، بیک اپ اور DR سہولت معاونت، اور ایگزٹ پلان کے ساتھ تعاون (ہوسٹ رسائی rotation، ماحول ہینڈ اوور) شامل ہیں۔ ہوسٹنگ انتظام میں تبدیلیاں (مثلاً، ہوسٹ تبدیل کرنا) S&ITD منظوری چاہتی ہیں اور اسکرو، ڈیٹا portability، اور تسلسل تحفظات برقرار رکھنے ضروری ہیں۔

13. سیکیورٹی ذمہ داریاں

آپریٹر کی سیکیورٹی ذمہ داریاں /specs/ur/11-security-compliance/ میں کنٹرول کیٹلاگ سے نکلتی ہیں اور معاہداتی طور پر پابند ہیں۔ آپریٹر کو معاہدے کی مدت اور منتقلی مدت کے دوران ان کنٹرولز کو نافذ، برقرار، اور ثبوت کے ساتھ پیش کرنا ہے۔

PPP-V-901 — غفلت کی وجہ سے سیکیورٹی واقعات کی کوئی علاج مدت نہیں۔ اوپر کے کنٹرولز برقرار رکھنے میں آپریٹر کی ناکامی کی وجہ سے ہونے والا تصدیق شدہ واقعہ فوری سروس کریڈٹ اور آپریٹر کی لاگت پر اصلاح کو چالو کرتا ہے؛ ایسا کوئی اہم واقعہ خاتمے کی وجہ ہے (PPP-V-101) اور اسکرو جاری کو چالو کرتا ہے۔

13.1 خلاف ورزی اطلاع ٹائم لائن

ذاتی یا خودمختار ڈیٹا تک کوئی تصدیق شدہ غیر مجاز رسائی یا اس کا اخراج ایک رپورٹ طلب واقعہ ہے: تصدیق کے 1 گھنٹے کے اندر S&ITD کو مطلع کریں؛ CERT-PK کو 24 گھنٹوں کے اندر مطلع کریں (SEC-092)؛ جہاں ضروری ہو متاثرہ افراد اور سندھ انفارمیشن کمیشن کو مطلع کریں۔ آپریٹر forensics کے ساتھ مکمل تعاون کرتا ہے اور ثبوت محفوظ رکھتا ہے (SEC-093)۔

13.2 افرادی سیکیورٹی

آپریٹر پلیٹ فارم یا اس کے ڈیٹا تک رسائی رکھنے والے تمام افرادی قوت کا موجودہ roster برقرار رکھتا ہے، جو S&ITD کی درخواست پر اور کسی بھی تبدیلی پر فراہم کیا جاتا ہے۔ روانہ ہونے والے افرادی قوت کی رسائی روانگی کے 1 گھنٹے کے اندر منسوخ اور ان کے secrets/devices واپس لیے جاتے ہیں؛ ایک تصدیق log ہوتی ہے۔ آپریٹر کسی بھی ایسے عملے کو فوراً ہٹاتا ہے جس پر S&ITD سیکیورٹی/دیانتداری کی بنیاد پر معقول اعتراض کرے۔

14. مفاد کا تصادم و مخالفِ بدعنوانی

SITP کی procurement اور آپریشن سندھ پبلک پروکیورمنٹ ریگولیٹری اتھارٹی (PEPRA) فریم ورک اور موجودہ وفاقی مخالفِ بدعنوانی قانون کے ساتھ ہم آہنگ ہیں۔ آپریٹر اور اس کے عملے کو کسی بھی حقیقی یا ظاہری مفاد کے تصادم سے گریز کرنا چاہیے اور معاہدے کے سلسلے میں کوئی بھی نامناسب فائدہ پیش، وعدہ، دینا یا قبول نہیں کرنا چاہیے۔

• PEPRA ہم آہنگی (PPP-V-1001)۔ آپریٹر کا تعلق، کوئی بھی جانشین procurement، اور thresholds سے زیادہ کوئی بھی ذیلی کنٹراكٹنگ PEPRA کے شفافیت، مقابلے، اور record-keeping قواعد پر عمل کرتے ہیں۔ یہ دستاویز RFP/ٹینڈر کے لیے تیار ہے (_context.md §9) تاکہ کوئی بھی دوبارہ ٹینڈر کھلا اور منصفانہ ہو۔
• اظہار۔ آپریٹر دستخط پر اور پیدا ہونے پر کوئی بھی مفاد تصادم (بشمول S&ITD افسران، مقابلہ بidders، یا ماحولیاتی نظام پارٹنرز کے ساتھ تعلقات) ظاہر کرتا ہے۔ S&ITD افسران بھی اپنے مفادات ظاہر کرتے ہیں۔
• شفافیت۔ معاہدے کی قیمت، ادائیگی میل اسٹونز، KPI کارکردگی، اور کوئی بھی تبدیلیاں ریکارڈ کی جاتی ہیں اور اندرونی آڈٹ اور پبلک اکاؤنٹس کمیٹی کی درخواست پر دستیاب ہیں۔ عوامی شفافیت ڈیش بورڈ (دستاویز 17 §11) مجموعی کارکردگی شائع کرتا ہے۔
• تحائف و مہمان نوازی۔ ایک سخت تحائف و مہمان نوازی رجسٹر برقرار رکھا جاتا ہے؛ نامناسب قدر سے زیادہ تحائف مسترد یا ظاہر کیے جاتے ہیں۔
• Whistleblowing۔ بدعنوانی یا تصادم کی رپورٹیں anonymous/whistleblower intake چینل (/specs/ur/24-trust-safety/) کے ذریعے کی جا سکتی ہیں؛ بدسلوکی کا انتقام ممنوع ہے۔
• نتائج۔ سزا، نااہلی، یا اس حصے کی تصدیق شدہ سنگین خلاف ورزی ایک وجہ کی بناء پر خاتمے کا محرک ہے (PPP-V-101)۔

15. تنازع حل

15.1 نافذ قانون

معاہدہ پاکستان کے قوانین، اور خاص طور پر سندھ حکومت پر لاگو قانون، بشمول سندھ procurement اور معاہدہ قانون کے تحت چلتا ہے۔ کراچی، سندھ کی عدالتوں کا دائرہ اختیار ہے، ذیل کی ثالثی شق کے تابع۔

15.2 حل کا سیڑھی

تنازعات کام کے تعلقات اور خدمت کے تسلسل کو برقرار رکھنے کے لیے مراحل میں حل کیے جاتے ہیں:

1. آپریشنل حل — پروگرام آفس کارکردگی جائزہ کیڈنس (§16) کے اندر روزمرہ مسائل حل کرتا ہے۔
2. مذاکرات — باقاعدہ تحریری نوٹس؛ S&ITD اور MAAHIR کے سینئر نمائندگان 15 کاروباری دنوں کے اندر مل کر حل کرتے ہیں۔
3. ثالثی — ایک غیر جانبدار ثالث (متفقہ یا مقرر) 30 کاروباری دنوں کے اندر حل کی کوشش کرتا ہے۔
4. Arbitration — حل نہ ہونے والے تنازعات کراچی میں Arbitration Act 1940 (ترمیم شدہ) / Recognition and Enforcement (Arbitration Agreements and Foreign Arbitral Awards) Act 2011 فریم ورک کے تحت binding arbitration میں جاتے ہیں، ایک واحد ثالث (یا اہم تنازعات کے لیے تین رکنی tribunal) کے ساتھ جو فریقین متفق ہوں یا قواعد کے مطابق مقرر ہوں۔

PPP-V-1101 — تنازع کے دوران تسلسل۔ آپریٹر کو کسی بھی تنازع کے دوران پلیٹ فارم چلاتے رہنا اور SLAs پورے کرنے ہیں، اور S&ITD کو غیر متنازع انوائس ادا کرتے رہنے ہیں، یہاں تک کہ تنازع حل ہو یا منتقلی پلان استعمال ہو۔ کوئی تنازع خدمت کی رکاوٹ کو جائز نہیں ٹھہراتا۔ اسکرو جاری اور منتقلی پلان (§11) تنازع کی حیثیت سے قطع نظر دستیاب رہتے ہیں۔

16. کارکردگی جائزہ کیڈنس

SLAs (§4) اور KPIs (§5) کے خلاف کارکردگی ایک متعین کیڈنس پر مشترکہ S&ITD–MAAHIR پروگرام آفس کے ذریعے جائزہ لی جاتی ہے، S&ITD قیادت تک اسکیلیشن راستوں کے ساتھ۔

17. معاہدہ تبدیلی مینجمنٹ

دائرہ کار، شیڈول، لاگت، یا کسی بھی SLA/KPI ہدف میں تبدیلیاں اس طرح کنٹرول کی جاتی ہیں کہ اس دستاویز کے تحفظات خاموشی سے کبھی کمزور نہ ہوں۔

• تبدیلی درخواست (CR)۔ کوئی بھی تبدیلی ایک تحریری CR کے طور پر rationale، اثر (دائرہ کار/شیڈول/لاگت/خطرہ)، اور متاثرہ شقوں (بشمول کوئی بھی SLA، KPI، اسکرو، IP، یا ایگزٹ شق) کے ساتھ اٹھائی جاتی ہے۔
• اثر جانچ۔ آپریٹر 5 کاروباری دنوں کے اندر اثر جانچ فراہم کرتا ہے؛ S&ITD تحفظات پر اثر کے لیے جائزہ لیتا ہے۔
• منظوری کا اختیار۔ معمولی CRs پروگرام آفس سطح پر منظور ہوتے ہیں؛ اہم CRs (دائرہ کار، threshold سے زیادہ لاگت، SLA/KPI ہدف تبدیلی، §§7–11 میں کوئی بھی تبدیلی) S&ITD ایگزیکٹو منظوری چاہتی ہیں اور، جہاں عوامی وعدوں کو متاثر کرتی ہوں، عوامی شفافیت ڈیش بورڈ سے ہم آہنگی۔
• تحفظات کا تحفظ۔ کوئی بھی تبدیلی اسکرو، IP ملکیت، ڈیٹا، یا ایگزٹ ذمہ داریوں (§§7–11) کو صریح، ریکارڈ شدہ ایگزیکٹو منظوری کے بغیر کمزور نہیں کر سکتی، اور کبھی اس طرح نہیں کہ پلیٹ فارم آپریٹر پر منحصر بن جائے۔
• ورژن کنٹرول۔ معاہدہ اور یہ دستاویز versioned ہیں؛ ہر ریلیز متعلقہ معاہدہ ورژن لے کر آتی ہے۔ تبدیلیاں log اور auditable ہیں۔

18. انشورنس و ذمہ داری

19. ایگزٹ تیاری چیک لسٹ

یہ چیک لسٹ تیاری جائزے (M10) کے لیے قبولیت کا آلہ ہے اور کسی بھی حقیقی منتقلی سے پہلے مشق (ڈرائی رن) کی جاتی ہے۔ ایک سبز چیک لسٹ وہ ثبوت ہے — وعدہ نہیں — کہ S&ITD پلیٹ فارم سنبھال سکتا ہے۔ حیثیت: ✓ لازمی پاس؛ ◐ لازمی-منظورِ-پلان-کے-ساتھ قابلِ قبول۔

20. حوالہ جات

20.1 اندرونی دستاویزات

• منصوبے کا سیاق (مقفل فیصلے): ../_context.md
• دستاویز کے روایات: ../_conventions.md
• روڈ میپ و ریلیز پلان: /specs/ur/14-roadmap-release/
• غیر فعال تقاضے (دستیابی، DR، پرائیویسی): /specs/ur/03-non-functional-reqs/
• سیکیورٹی و تعمیل (کنٹرولز، IR، خلاف ورزی اطلاع): /specs/ur/11-security-compliance/
• تجزیات و KPIs (وینڈر اسکور کارڈ ماخذ): /specs/ur/17-analytics-kpis/
• ٹیک فن تعمیر (اسکرو آرٹیفیکٹس، DR topology): /specs/ur/15-tech-architecture/
• حکمرانی و قانونی (مینڈیٹ، MoUs، RTI): /specs/ur/22-governance-legal/
• اعتماد و سلامتی (whistleblower چینل): /specs/ur/24-trust-safety/

20.2 بیرونی فریم ورکس

• سندھ پبلک پروکیورمنٹ ریگولیٹری اتھارٹی (PEPRA) — procurement شفافیت و مقابلہ۔
• سندھ شفافیت و حقِ معلومات ایکٹ 2016 — قانونی آخری تاریخیں و اظہار۔
• پاکستان Arbitration Act 1940 (ترمیم شدہ) اور Recognition and Enforcement (Arbitration Agreements and Foreign Arbitral Awards) Act 2011 — تنازع حل۔
• CERT-PK — واقعہ ہم آہنگی و اطلاع توقعات۔
• OWASP ASVS Level 2 — ایپلیکیشن سیکیورٹی تصدیق بیس لائن۔

دستاویز کا اختتام۔ اردو اور سندھی متوازی تراجم (ur.md، sd.md) اس مرجع ڈھانچے کی عین پیروی کرتے ہیں۔