ٹکٹ ورک فلو

سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) پر ہر ٹکٹ کے لیے مستند لائف سائیکل، SLA/اسکیلیشن، حل کے ثبوت کا گیٹ، TRI/MoM، اور غیر معمولی معاملات کی تفصیلی ہدایت۔

1. حد و قاموس

یہ دستاویز تعین کرتی ہے کہ ایک ٹکٹ کیسے پیدا ہوتا ہے، راؤٹ ہوتا ہے، SLA کے خلاف کام کیا جاتا ہے، اسکیلیٹ کیا جاتا ہے، حل کے ثبوت کے ساتھ ثابت کیا جاتا ہے، اختیاری طور پر دوبارہ کھولا یا اس پر اپیل کی جاتی ہے، اور بالآخر بند کیا جاتا ہے — نیز میٹنگز (TRI) اور ان کی رودادیں (MoM) لائف سائیکل میں کس طرح منسلک ہوتی ہیں۔ یہ tickets پر status فیلڈ، sla_definitions ٹیبل، ticket_history / audit_events لاگز، اور تمام تبدیلی کے محافظوں (transition guards) کے لیے واحد مصدرِ حق ہے۔

قاموس (مختصر صورت؛ مکمل کے لیے _glossary.md دیکھیں):

یہاں بیان کردہ تمام صلاحیتیں انفرادی طور پر فیچر فلیگ ماڈیول (Q) کے ذریعے آن/آف کی جا سکتی ہیں، اور انفرادی طور پر §15 میں بیان کردہ فی محکمہ/فی زمرہ کنفیگریشن ٹیبلز کے ذریعے مرتب کی جا سکتی ہیں۔

2. ٹکٹ کی حالتیں

ہر ٹکٹ کی کسی بھی وقت بالکل ایک حیثیت ہوتی ہے۔ مکمل شمار مقفل ہے؛ داخلے اور خارج ہونے کے قواعد پر بحث نہیں ہو سکتی۔ تبدیلیاں سروس سائیڈ پر توثیق کی جاتی ہیں اور ہر تبدیلی ایک audit_events قطار پیدا کرتی ہے (§13 ملاحظہ کریں)۔

حالتوں کے مقامی نام (ایک بار برائے فہم): New (نیا)، Triaged (فرز بندی شدہ)، Assigned (تفویض شدہ)، In Progress (جاری)، Awaiting Parties (فریقین کا انتظار)، Resolved (حل شدہ)، Closed (بند)، Reopened (دوبارہ کھولا)، Escalated (اسکیلیٹڈ)، On Hold (روکا ہوا)، Cancelled/Withdrawn (منسوخ/واپس لیا گیا)، Appealed (اپیل کی گئی)۔

2.1 حالتوں کی تعریف اور میٹرکس

نوٹس:

• Escalated ایک اوورلے حیثیت ہے۔ پچھلی "حقیقی" کام کرنے والی حالت (Assigned / In Progress / Awaiting Parties) escalation_context میں محفوظ رہتی ہے اور اسکیلیشن ختم یا عمل میں لائے جانے پر ٹکٹ اسی حالت میں واپس آتا ہے۔ اس طرح اسکیلیشن کے عروج کے دوران افسر کا سیاق ضائع نہیں ہوتا۔
• Awaiting Parties اور On Hold دونوں SLA کلاک روکتے ہیں لیکن اداکار اور نیت میں فرق ہے: Awaiting Parties معمول کی معلومات طلب کرنے کا بلاک ہے؛ On Hold کسی افسر یا نگرانی کردار کی طرف سے واضح وجہ سے بندھا معطل کرنا ہے۔
• ٹکٹ کو زیادہ تر غیر آخری حالتوں سے Cancelled/Withdrawn کیا جا سکتا ہے۔ اس عمل کے لیے وجہ درکار ہوتی ہے اور یہ ایک آڈٹ ایونٹ پیدا کرتا ہے؛ کمپنی کی طرف سے صرف Primary/Admin نمائندے واپس لے سکتے ہیں۔
• آخری حالتیں Closed اور Cancelled/Withdrawn ہیں۔ آخری حالتوں سے اخراج صرف §8 میں بیان کردہ مختصر دوبارہ کھولنے/اپیل کی ونڈوز ہیں۔

2.2 کون تبدیل کر سکتا ہے (عالی سطح — مکمل RBAC /specs/ur/04-roles-permissions/ میں)

3. اسٹیٹ مشین ڈایاگرام

نیچے دیا گیا لائف سائیکل مستند اسٹیٹ مشین ہے۔ محافظ (ثبوت گیٹ، حساس منظوری، دوبارہ کھولنے کی ونڈو وغیرہ) متعلقہ سیکشنز میں بیان کردہ ہیں اور دکھائی گئی تبدیلیوں پر لاگو ہوتے ہیں۔

میرمیڈ نوڈ ناموں میں خالی جگہیں نہیں ہو سکتیں، اس لیے Cancelled/Withdrawn کو CancelledWithdrawn اور Awaiting Parties کو AwaitingParties کے طور پر دکھایا گیا ہے۔ سسٹم پر status enum اپنے مستند ناموں (خالی جگہ/سلیش کے ساتھ) برقرار رکھتا ہے۔

تحریری بہاؤ کی وضاحت۔ فائلنگ یا آنے والے چینل کی آمد پر ٹکٹ New کے طور پر پیدا ہوتا ہے۔ S&ITD اسے Triaged میں فرز بند کرتا ہے، زمرہ/ترجیح/SLA مقرر کرتا ہے، اور کسی محکمے کے سیکشن کو راؤٹ کرتا ہے، جس سے یہ Assigned ہو جاتا ہے۔ تفویض شدہ افسر کا پہلا باقاعدہ جواب ٹکٹ کو In Progress میں بدل دیتا ہے اور FRT کلاک روک دیتا ہے (ریذولوشن کلاک چلتا رہتا ہے)۔ جب بھی کمپنی کو معلومات فراہم کرنی ہوں تو کام In Progress اور Awaiting Parties کے درمیان متبادل ہوتا ہے؛ ہر Awaiting Parties میں داخلہ SLA کلاک روکتا ہے اور ہر واپسی اسے دوبارہ شروع کرتی ہے۔ کسی بھی کلاک کے اپنے SLA کی خلاف ورزی ٹکٹ کو Escalated میں بدل دیتی ہے، جو ایک اوورلے حالت ہے جو پچھلا کام کرنے کا سیاق محفوظ رکھتی ہے اور متعلقہ نگرانی درجے کو مطلع کرتی ہے۔

جب افسر مکمل کر لیتا ہے، تو وہ حل کے ثبوت کے گیٹ سے گزرتا ہے (≥1 ثبوت کا منسلکہ + حل کی نوٹ؛ حساس/VIP ٹکٹس کو مزید Chair/DG منظوری درکار ہوتی ہے) اور ٹکٹ Resolved ہو جاتا ہے۔ Resolved سے تین چیزیں ہو سکتی ہیں: کمپنی واضح طور پر قبول کرے → Closed؛ CSAT ونڈو (طے شدہ 7 دن) بغیر کسی عمل کے ختم ہو جائے → آٹو-Closed؛ یا کمپنی ونڈو کے اندر مسترد کر دے → Reopened، جو اپنی پچھلی کام کرنے والی حالت میں دوبارہ کام کی قطار میں داخل ہوتا ہے۔ Closed سے (یا براہِ راست Resolved سے) کمپنی اپیل ونڈو کے اندر CPGRAMS طرز کی Appeal بھی دائر کر سکتی ہے؛ اپیلز اگلے نگرانی درجے پر جائزہ لی جاتی ہیں اور یا تو برقرار رکھی جاتی ہیں (واپس In Progress) یا مسترد کر دی جاتی ہیں (آخری Closed)۔ On Hold زیادہ تر کام کرنے والی حالتوں سے استعمال ہونے والا واضح، وجہ سے بندھا معطل ہے۔ Cancelled/Withdrawn ایک مختصر غلطی سے واپس لی گئی راہ کے سوا آخری ہے۔ حقیقی آخری حالتیں صرف Closed اور Cancelled/Withdrawn ہیں۔

4. فائلنگ اور ٹرائج کا بہاؤ

4.1 فائلنگ

ایک ٹکٹ ماڈیول K (ملٹی چینل اندراج) کے کسی بھی چینل سے شروع ہو سکتا ہے: ویب پورٹل، PWA/موبائل ایپ، کوئی آنے والی ای میل، SMS، واٹس ایپ پیغام، ٹول فری IVR/آواز کی ٹرانسکرپشن، یا S&ITD سہولت کار کی طرف سے حاضری/آف لائن اندراج۔ تمام چینلز ایک ہی tickets ٹیبل پر آ کر یکجا ہوتے ہیں؛ intake_channel فیلڈ اصل کو ریکارڈ کرتا ہے۔

اسمارٹ فائلنگ (AI معاون):

• زمرے کی تجویز۔ جیسے جیسے کمپنی شکایت ٹائپ کرتی ہے، AI (ماڈیول E) ماضی کے ٹکٹس اور سروس کیٹلاگ سے نیمانی مماثلت کی بنیاد پر سب سے زیادہ ممکنہ زمرہ/ذیلی زمرہ اور راؤٹڈ محکمہ تجویز کرتا ہے۔ فائلر قبول یا اوورائیڈ کر سکتا ہے۔
• مماثل ٹکٹ کا انحراف۔ اگر کوئی مماثل کھلا یا حال ہی میں حل شدہ ٹکٹ موجود ہو، تو پورٹل جمع کرانے سے پہلے اسے نمایاں کرتا ہے: "ہو سکتا ہے آپ کا جواب پہلے ہی موجود ہو — SITP-2026-LBR-000098 دیکھیں۔" اگر کمپنی تصدیق کرے کہ موجودہ ٹکٹ ان کے مسئلے کا احاطہ کرتا ہے، تو کوئی نیا ٹکٹ نہیں بنایا جاتا (انحراف کو اینالٹکس ایونٹ کے طور پر ٹریک کیا جاتا ہے)۔ اگر نہیں، تو فائلنگ آگے بڑھتی ہے۔
• فوریّت اور جذباتی حالت کا اشارہ۔ AI ایک ترجیح (Urgent/Normal/Low) تجویز کرتا ہے اور جذباتی حالت کو نمایاں کرتا ہے؛ S&ITD ٹرائج اس کی ٹرائج کے دوران توثیق یا اوورائیڈ کرتا ہے۔
• اندراج پر PII کی حذف و ترمیم۔ مفت متن میں شناخت شدہ PII کو ماڈیول E کے مطابق، محفوظ کرنے سے پہلے، فلگ/ریڈیکٹ کیا جاتا ہے۔

مسودہ اور بعد میں محفوظ کریں (FR-TKT-014 کو پورا کرتا ہے)۔ کمپنی نمائندہ ایک نامکمل ٹکٹ کو اپنی ذاتی مسودہ اسٹور میں محفوظ کر سکتا ہے۔ مسودے S&ITD یا محکمے کو نظر نہیں آتے، کوئی ٹریکنگ آئی ڈی استعمال نہیں کرتے، اور ان کی قابلِ ترتیب رٹینشن (طے شدہ 30 دن) ہوتی ہے۔ مسودہ جمع کرنے سے وہ New ٹکٹ میں تبدیل ہو جاتا ہے۔

متحرک مشروط اندراج فارم۔ اندراج فارم سروس کیٹلاگ اور منتخب زمرہ/ذیلی زمرے سے چلتا ہے۔ "لیبر — ادائیگی باقی" کو منتخب کرنے سے مختلف فیلڈز (آخری تنخواہ کی تاریخ، رقم، ملازمین کی تعداد) نظر آتی ہیں نسبتاً "SECP — نام محفوظ کرنے کے تنازعہ" کے (تجویز کردہ نام، محفوظ کرنے کا نمبر، مسترد نامہ)۔ مشروط حصے، لازمی فیلڈ کے قواعد، اور اجازت شدہ منسلکہ اقسام intake_form_schema میں فی زمرہ مرتب کی جاتی ہیں۔

ٹریکنگ آئی ڈی کی تخلیق۔ کامیاب جمع کرانے پر، سسٹم راؤٹڈ محکمے کے لیے اگنا تسلسل نمبر مختص کرتا ہے اور SITP-YYYY-<DEPT>-<NNNNNN> (مثلاً SITP-2026-LBR-000123) تشکیل دیتا ہے۔ مختصاتی عمل ایٹامک ہے (DB لینزکشن + فی محکمہ تسلسل پر قطار لاک)۔ آئی ڈی فوراً فائلر کو واپس کی جاتی ہے اور تمام بعد کی مواصلت کے لیے مستند حوالہ ہے۔ فائلر کی پسندیدہ زبان (EN/UR/SD) میں اس کی پسندیدہ چینل کے ذریعے ایک تصدیقی پیغام بھیجا جاتا ہے۔

4.2 ٹرائج

S&ITD ٹرائج افسران New ٹکٹس کی ایک قطار دیکھتے ہیں۔ ہر ایک کے لیے، وہ AI سے تجویز کردہ زمرہ، ذیلی زمرہ، ترجیح، راؤٹڈ محکمہ/سیکشن، SLA تعریف، اور حساسیت فلگ کی توثیق یا اوورائیڈ کرتے ہیں۔ وہ VIP بھی فلگ کر سکتے ہیں (ترجیحی شعبے کی کمپنیوں کے فائلرز، بڑی روزگار، غیر ملکی سرمایہ کاری کے معاملات) جو حساس راستے سے راؤٹ ہوتے ہیں۔ ایک مرتبہ فرز بندی ہونے پر، ٹکٹ Triaged میں چلا جاتا ہے اور منزل محکمے کی قطار میں نمودار ہوتا ہے۔

4.3 فائلنگ اور ٹرائج کے بہاؤ کا ڈایاگرام

تحریری وضاحت۔ ایک فائلر (یا آنے والے چینل ایڈاپٹر) سے بہاؤ شروع ہوتا ہے؛ مستند فائلرز ایک محفوظ مسودہ دوبارہ شروع کر سکتے ہیں، جبکہ گمنام/وہسٹل بلوور اندراج شروع سے ہی محدود نظر انداز رکھتا ہے۔ متحرک اندراج فارم منتخب زمرے کی بنیاد پر رینڈر ہوتا ہے، جس میں فائلر کے ٹائپ کرنے پر AI زمرہ اور منزل محکمہ تجویز کرتا ہے۔ جمع کرانے سے پہلے، سسٹم مماثل ٹکٹ انحراف چلاتا ہے: اگر ممکنہ نقل یا پہلے جواب دیا ٹکٹ موجود ہو، تو فائلر کو نیا ٹکٹ نہ بنانے کا اختیار دیا جاتا ہے۔ اگر وہ آگے بڑھیں، تو منسلکات AV سکین اور خفیہ کیے جاتے ہیں، فارم جمع کیا جاتا ہے، اور SITP-YYYY-<DEPT>-<NNNNNN> فارمیٹ میں ٹریکنگ آئی ڈی ایٹامک طور پر مختص ہوتی ہے۔ ٹکٹ New میں داخل ہوتا ہے اور S&ITD ٹرائج قطار میں آتا ہے، جہاں ٹرائج افسر زمرہ، ترجیح، SLA، منزل، اور حساسیت کی توثیق یا اوورائیڈ کرتا ہے۔ توثیق پر ٹکٹ Triaged ہو جاتا ہے، منزل محکمے کی سیکشن قطار میں داخل ہوتا ہے، اور کسی افسر کو تفویض کیا جاتا ہے — یا تو سیکشن ہیڈ یا AI آٹو روٹر کی طرف سے — جس سے وہ Assigned ہو جاتا ہے۔

5. SLA ماڈل

5.1 SLA تعریفیں

ہر ٹکٹ sla_definitions میں بالکل ایک قطار سے بندھا ہوتا ہے، جو ٹرائج میں (department, category, priority) کے ذریعے منتخب کیا جاتا ہے۔ ہر قطار دو ٹائمرز رکھتی ہے:

• پہلا جواب وقت (FRT) — تخلیق سے تفویض شدہ محکمے کے پہلے باقاعدہ جواب تک (وہ جواب جو ٹکٹ کو Assigned → In Progress میں بدل دیتا ہے)۔ اعترافات، "ہم اس پر غور کر رہے ہیں"، اور خودکار رسیدیں FRT پوری نہیں کرتیں۔
• حل کا وقت — تخلیق سے ثبوتِ گیٹ والے Resolved تک۔

طے شدہ ہدف (فی محکمہ/زمرہ اوورائیڈ کے قابل):

"کاروباری دن" منزل محکمے کے کاروباری اوقات اور ٹائم زون (طے شدہ Asia/Karachi، PKT) میں سندھ کی عام چھٹیوں اور ویک اینڈز ہٹانے کے بعد شمار کیا جاتا ہے۔ طے شدہ اقدار sla_definitions میں فی (department, category, priority) اوورائیڈ کے قابل ہیں؛ کسی قطار پر NULL حل کا وقت کا مطلب ہے "کوئی حل SLA نہیں" (صرف مشاورتی — RTI جیسی کھلی قسموں کے لیے استعمال ہوتا ہے جہاں قانونی آخری تاریخیں اس کی جگہ لاتی ہیں)۔

5.2 SLA کلاک — کب چلتا ہے، رکتا ہے، دوبارہ شروع ہوتا ہے

SLA کلاک ہر ٹائمر کے خلاف جمع کاروباری وقت کا ایک یکساں شمار کنندہ ہے۔ فی ٹکٹ دو آزاد کلاکیں چلتی ہیں: FRT کلاک اور ریذولوشن کلاک۔ دونوں نیچے دیے گئے یکساہ چلنے/رکنے کے قواعد بانٹتے ہیں، سوائے اس کے کہ FRT کلاک ایک مرتبہ FRT پوری ہونے پر مستقل طور پر رک جاتا ہے۔

کلاک چلتا ہے جب حالت ان میں سے کوئی بھی ہو: New، Triaged، Assigned، In Progress، Reopened، Appealed (فعال جائزے کے دوران)، Escalated (اوورلے — محفوظ کام کرنے والی حالت کے خلاف چلتا ہے)۔

کلاک رکتا ہے جب:

1. حالت Awaiting Parties ہو (کمپنی یا تیسرے فریق کا جواب باقی)۔
2. حالت On Hold ہو (وجہ سے بندھا واضح روک)۔
3. موجودہ وال کلاک وقت محکمے کی مرتب کردہ کاروباری اوقات سے باہر ہو (طے شدہ پیر–جمعہ 09:00–17:00 PKT؛ dept_business_hours میں فی محکمہ قابلِ ترتیب)۔
4. موجودہ وال کلاک تاریخ holiday_calendar میں درج سندھ کی عام چھٹی ہو۔
5. موجودہ وال کلاک تاریخ اس محکمے کے لیے ویک اینڈ ہو (طے شدہ ہفتہ + اتوار؛ قابلِ ترتیب — کچھ محاکم ہفتہ کو کام کرتے ہیں)۔

کلاک دوبارہ شروع ہوتا ہے جب:

• کمپنی جواب دے (حالت Awaiting Parties → In Progress واپس آئے)، یا
• On Hold کسی مجاز اداکار کی طرف سے اٹھا لیا جائے، اور
• موجودہ وال کلاک وقت غیر چھٹی، غیر ویک اینڈ دن میں کاروباری اوقات کے اندر ہو۔

اگر دوبارہ شروع کا ایونٹ کاروباری اوقات سے باہر ہو، تو کلاک اگلے کاروباری گھنٹے کے آغاز پر دوبارہ شروع ہوتا ہے۔ گزرا ہوا شمار کنندہ ہر حالت کی تبدیلی پر محفوظ کیا جاتا ہے تاکہ سروس کے دوبارہ شروع ہونے سے SLA حالت کبھی ضائع نہ ہو۔

قریب خلاف ورزی اور خلاف ورزی۔ SLA انجن ہر ٹک (طے شدہ 1 منٹ کرون + تبدیلی پر) ہر کھلے ٹکٹ کے گزرے ہوئے وقت کا اس کے ٹائمرز کے خلاف جائزہ لیتا ہے۔ قابلِ ترتیب حدوں پر (طے شدہ: ٹائمر کا 80% = قریب خلاف ورزی کی تنبیہ، 100% = خلاف ورزی)، انجن audit_events پیدا کرتا ہے اور نوٹیفکیشن میٹرکس (§12) اور اسکیلیشن لیڈر (§6) کو متحرک کرتا ہے۔

5.3 SLA کلاک ڈایاگرام

تحریری وضاحت۔ SLA کلاک صرف کاروباری وقت جمع کرتا ہے — کبھی راتیں، ویک اینڈز، یا سندھ کی عام چھٹیاں نہیں — اور صرف اس وقت جب ٹکٹ "محکمہ ذمہ دار" حالت میں ہو (New، Triaged، Assigned، In Progress، Reopened، Appealed-تحتِ جائزہ، یا Escalated ایک کام کرنے والی حالت کے سیاق کے خلاف)۔ Awaiting Parties یا On Hold میں کوئی بھی تبدیلی کلاک روکتی ہے؛ In Progress میں واپسی کی متعلقہ تبدیلی اسے دوبارہ شروع کرتی ہے، لیکن صرف اگر وال کلاک وقت غیر چھٹی ویک دن پر منزل محکمے کے کاروباری اوقات کے اندر ہو۔ FRT کلاک مستقل طور پر رک جاتا ہے جب پہلا باقاعدہ جواب FRT پورا کرے، جبکہ ریذولوشن کلاک ثبوتِ گیٹ والے Resolved تک چلتا رہتا ہے۔ قریب خلاف ورزی (طے شدہ ٹائمر کا 80%) اور خلاف ورزی (100%) کی حدیں آڈٹ ایونٹس پیدا کرتی ہیں اور اسکیلیشن لیڈر چلاتی ہیں؛ چلتا کلاک خلاف ورزی کے بعد بھی جمع کرتا رہتا ہے تاکہ خلاف ورزی کی مدت ناپی جا سکے۔

5.4 کاروباری اوقات اور چھٹیوں کا کیلنڈر

• dept_business_hours: فی محکمہ (weekday, open_time, close_time, timezone) کی قطاریں۔ تمام محاکم کے لیے طے شدہ: پیر–جمعہ 09:00–17:00 Asia/Karachi۔ جو محاکم ہفتہ کو کام کرتے ہیں یا بدلی اوقات رکھتے ہیں وہ اپنی قطاریں مرتب کرتے ہیں۔
• holiday_calendar: سندھ حکومت کی عام چھٹیاں، جنہیں S&ITD سالانہ حاصل اور اپ ڈیٹ کرتا ہے (عید الفطر، عید الاضحیٰ، 9ویں/10ویں/11ویں محرّم، 12ویں ربیع الاوّل، پاکستان ڈے، یومِ آزادی، یومِ اقبال، یومِ مزدور، عید میلاد النبی، عاشورہ، چہلم، اور کوئی بھی مطلوبہ موقعی چھٹیاں)۔ ہجری تاریخ کی چھٹیاں اسلامی کیلنڈر کے خلاف شمار کی جاتی ہیں اور ہر سال گرگوری تواریخ میں حل کی جاتی ہیں؛ دونوں کیلنڈر UI میں _context.md کے §2 کے مطابق دکھائے جاتے ہیں۔
• RTI قانونی آخری تاریخیں۔ RTI کے زمرے میں آنے والے ٹکٹس کے لیے (سندھ شفافیت و حقِ معلومات ایکٹ 2016)، قانونی آخری تاریخیں (طے شدہ 10 کاروباری دن، 10 مزید کے قابلِ توسیع) اوپر کی جدول پر فوقیت رکھتی ہیں اور statutory = true کے نشان کے ساتھ ایک علیحدہ SLA قطار کے طور پر مرتب کی جاتی ہیں۔

6. اسکیلیشن لیڈر

6.1 لیڈر کا ڈھانچہ

جب کسی ٹکٹ کے حل کی SLA خلاف ورزی کرتی ہے اور وہ حل نہیں ہوتا، تو وہ ایک قابلِ ترتیب نگرانی لیڈر پر چڑھتا ہے۔ طے شدہ لیڈر (مقفل فیصلہ، escalation_ladders میں فی محکمہ/زمرہ اوورائیڈ کے قابل) یہ ہے:

یہی لیڈر S&ITD کے اندر بھی لاگو ہوتا ہے — S&ITD سہولت کار بھی ہے اور اپنے ٹکٹس کے ساتھ ایک محکمہ بھی (مثلاً اپنے سیکشنز کے خلاف)، اس لیے S&ITD اندرونی ٹکٹ S&ITD سیکشن افسر → S&ITD ایڈیشنل/جوائنٹ DG → S&ITD سیکریٹری → SACM تک اسکیلیٹ ہوتا ہے۔ متحرک اور درجے (department, category) پر محدود escalation_ladders قطار کے مطابق قابلِ ترتیب ہیں۔

متحرک SLA سے منسلک ہیں۔ مختصراً، +2/+5/+10 شمار حل-SLA کی خلاف ورزی کے بعد کاروباری دن ہیں، تخلیق کے بعد نہیں۔ جو ٹکٹ اپنی SLA کے اندر حل ہو جائے وہ کبھی اسکیلیٹ نہیں ہوتا۔ خلاف ورزی کرنے والا ٹکٹ ہر مرتبہ کی قابلِ ترتیب مدت پر ایک درجہ چڑھتا ہے یہاں تک کہ حل ہو جائے یا اختیاراتِ عمل رکھنے والے نگرانی اداکار کی طرف سے فورس کلوز ہو۔

6.2 قابلِ ترتیب نگرانی اختیارات

ہر نگرانی درجے کو فی محکمہ یا تو صرف اطلاع یا عمل کے طور پر مرتب کیا جاتا ہے۔ کنفیگریشن (department, tier) کے ذریعے oversight_powers میں رہتی ہے۔

علامات _conventions.md §8 کے مطابق: ✓ اجازت · ✗ مسترد · ◐ مشروط/قابلِ ترتیب۔

طے شدہ پالیسی یہ ہے: درجے 1 (DG) اور 2 (سیکریٹری) عمل والے ہیں، درجہ 3 (وزیر/SACM) اطلاع + ہدایت والا ہے؛ یہ فی محکمہ اوورائیڈ کے قابل ہے۔ حساس/VIP بندش کی منظوری درجے سے قطع نظر ہمیشہ Chair/DG کے پاس رہتی ہے۔

6.3 الرٹس اور آڈٹ

• قریب خلاف ورزی الرٹ (کسی بھی ٹائمر کا 80%، قابلِ ترتیب): تفویض شدہ افسر + سیکشن ہیڈ + ناظرین کو ای میل/ان-ایپ کے ذریعے مطلع کریں؛ SMS اگر مرتب ہو۔
• خلاف ورزی الرٹ (کسی بھی ٹائمر کا 100%): افسر + سیکشن ہیڈ + ناظرین + اگلا نگرانی درجہ ای میل/ان-ایپ/SMS کے ذریعے مطلع کریں؛ درجہ ≥ 2 کے لیے واٹس ایپ۔
• ہر اسکیلیشن ایونٹ audit_events میں ایک غیر تبدیل شدہ قطار لکھتا ہے (type = escalation، actor = system یا actor = oversight-user، tier، reason، timestamp) اور متعلقہ ticket_history اندراج۔ ٹکٹ کی status Escalated ہو جاتی ہے جبکہ escalation_context پچھلی کام کرنے والی حالت برقرار رکھتا ہے۔
• دہرائی اسکیلیشن سے نمٹنا۔ اگر کوئی ٹکٹ ڈی اسکیلیٹ ہو (مثلاً In Progress میں دوبارہ شروع) اور پھر دوبارہ خلاف ورزی کرے، تو وہ اسی درجے پر جہاں سے چھوڑا تھا لیڈر میں دوبارہ داخل ہوتا ہے (کبھی درجہ 1 پر ری سیٹ نہیں) جب تک کہ اختیاراتِ عمل رکھنے والا نگرانی اداکار واضح طور پر اسے ری سیٹ نہ کرے۔ ہر دہرائی اسکیلیشن ٹکٹ اور تفویض شدہ افسر/سیکشن پر ایک escalation_count اور repeat_offender فلگ بڑھاتی ہے، جو نظامی مسئلے کی نشاندہی کے لیے اینالٹکس (ماڈیول I) میں نظر آتی ہے۔

6.4 اسکیلیشن ترتیب ڈایاگرام

تحریری وضاحت۔ SLA انجن خلاف ورزی کا پتہ لگاتا ہے اور فوراً ٹکٹ کو Escalated میں بدل دیتا ہے، audit_events میں ایک خلاف ورزی ایونٹ اور درجہ-1 اسکیلیشن ایونٹ لکھتا ہے، اور افسر، سیکشن ہیڈ، اور محکمے کے DG کو مطلع کرتا ہے جو ناظر کے طور پر شامل ہوتا ہے۔ 2 مزید حل نہ ہونے والے کاروباری دنوں کے بعد، انجن درجہ 2 (سیکریٹری) پر اسکیلیٹ کرتا ہے، ای میل/ان-ایپ/SMS/واٹس ایپ ترسیل اور ناظر کی اضافے کے ساتھ۔ 5 مزید حل نہ ہونے والے کاروباری دنوں کے بعد، یہ درجہ 3 (SACM اور S&ITD سیکریٹری) پر اسکیلیٹ کرتا ہے، جو معیاری چینلز کے علاوہ ایک رسمی ہدایت نامہ خط متحرک کرتا ہے۔ ہر درجے پر، اگر کنفیگریشن عمل کے اختیارات دیتی ہے، تو نگرانی اداکار دوبارہ تفویض، SLA اوورائیڈ، فورس ریذولوشن، یا پابند ہدایت نامہ جاری کر سکتا ہے — جن میں سے ہر ایک خود آڈٹ ہوتا ہے۔ اگر درجہ صرف اطلاع والا ہو، تو ٹکٹ Escalated رہتا ہے یہاں تک کہ کام کرنے والا افسر ثبوتِ گیٹ والا حل جمع کرے، جس پر انجن ڈی اسکیلیشن لاگ کرتا ہے اور ٹکٹ کو Resolved یا اس کی پچھلی کام کرنے والی حالت میں لے جاتا ہے۔

7. حل کے ثبوت کا گیٹ

7.1 گیٹ

کوئی ٹکٹ تب تک Resolved میں نہیں جا سکتا جب تک درج ذیل سب پوری نہ ہوں:

1. ≥1 ثبوت کا منسلکہ ٹکٹ پر موجود ہو (ثبوت کی زمرے کے تحت دائر، AV سکین، خفیہ — ماڈیول D)۔ قابلِ قبول ثبوت کی اقسام evidence_schema میں فی زمرہ مرتب ہوتی ہیں (مثلاً دستخط شدہ تصفیہ، ادائیگی کا ثبوت، درست لائسنس، NOC، سرکاری خط)۔
2. حل کی نوٹ تفویض شدہ افسر کی طرف سے جمع کی جائے جو کیا گیا اس کی وضاحت کرے، منسلک ثبوت کے حوالے کے ساتھ۔
3. صرف حساس/VIP ٹکٹس: تجویز کردہ حل کی تبدیلی سے پہلے واضح Chair/DG منظوری (§7.3 دیکھیں)۔
4. بین المحاکم ٹکٹس: ہر منسلک ذیلی ٹاسک/محکمے کو انفرادی طور پر خود کو حل شدہ نشان زد کرنا ہوگا (یا لیڈ محکمے کی طرف سے واضح معافی)۔

گیٹ PATCH /tickets/:id/status تبدیلی پر سروس سائیڈ نافذ کیا جاتا ہے؛ اگر کوئی پیش شرط ناکام ہو تو API 409 Conflict متداول خرابی کے ساتھ لوٹاتا ہے۔ UI پیش شرط پوری ہونے تک "Resolve" ایکشن کو غیر فعال رکھتا ہے۔

7.2 آٹو کلوز منطق

ایک مرتبہ Resolved ہونے پر، ٹکٹ CSAT ونڈو (طے شدہ 7 کیلنڈر دن، csat_config میں عالمی اور فی محکمہ قابلِ ترتیب) میں داخل ہوتا ہے۔ اس ونڈو کے دوران:

• کمپنی کو (الف) حل قبول کرنے، (ب) CSAT کے ذریعے اس کی درجہ بندی (1–5 ستارے + اختیاری مفت متن)، یا (ج) وجہ کے ساتھ دوبارہ کھولنے کی دعوت دی جاتی ہے۔
• آٹو کلوز اس وقت متحرک ہوتا ہے جب یا تو کمپنی واضح طور پر قبول کرے، یا CSAT ونڈو بغیر کسی عمل کے گزر جائے۔ آٹو کلوز پر ٹکٹ Closed (آخری) میں چلا جاتا ہے اور ایک بندش کا نوٹس بھیجا جاتا ہے۔
• اگر کمپنی خراب CSAT ریٹنگ (طے شدہ ≤ 2 ستارے) جمع کرائے، تو سسٹم اپیل راستہ (§8) فعال کرتا ہے اور اسے کمپنی کے UI میں نمایاں کرتا ہے۔
• اگر کمپنی ونڈو کے اندر واضح طور پر مسترد کرے، تو ٹکٹ Reopened میں چلا جاتا ہے اور دوبارہ کام کی قطار میں داخل ہوتا ہے۔

7.3 حساس / VIP بندش کی منظوری

جن ٹکٹس پر sensitive = true (قانونی/سیاسی انکشاف، VIP فائلر، غیر ملکی سرمایہ کاری، بڑا واقعہ) یا vip = true فلگ ہو، ثبوت گیٹ ایک چوتھی پیش شرط شامل کرتا ہے: Resolved کی اجازت سے پہلے تجویز کردہ حل پر ایک Chair یا DG منظوری ریکارڈ کی جانی چاہیے۔ تفویض شدہ افسر حل پیکج (ثبوت + نوٹ) جمع کرتا ہے؛ یہ محکمے کی Chair/DG منظوری قطار پر راؤٹ ہوتا ہے؛ منظوری پر گیٹ کھلتا ہے اور افسر Resolved میں بدل سکتا ہے۔ مسترد ہونے پر ٹکٹ In Progress میں واپس آتا ہے، Chair/DG کی وجہ منسلک کیے ہوئے۔ منظوری خود ایک آڈٹ شدہ ایونٹ ہے جس میں اداکار، ٹائم سٹیمپ، اور فیصلہ شامل ہیں۔

7.4 حل کے ثبوت کے گیٹ کا ڈایاگرام

تحریری وضاحت۔ In Progress سے افسر ٹکٹ کو حل کے لیے تیار نشان زد کرتا ہے اور ثبوت گیٹ جائزہ لیتا ہے: کم از کم ایک ثبوت کا منسلکہ اور حل کی نوٹ موجود ہونی چاہیے، بصورتِ دیگر تبدیلی 409 Conflict کے ساتھ بلاک کر دی جاتی ہے اور ٹکٹ In Progress میں رہتا ہے۔ حساس/VIP ٹکٹس کے لیے پیکج مزید Chair/DG منظوری قطار پر راؤٹ ہوتا ہے؛ منظوری گیٹ کھولتی ہے جبکہ مسترد ہونا ٹکٹ کو ریکارڈ کردہ وجہ کے ساتھ In Progress میں لوٹاتا ہے۔ گیٹ صاف ہونے پر ٹکٹ Resolved ہو جاتا ہے اور CSAT ونڈو شروع ہوتی ہے (طے شدہ 7 کیلنڈر دن)۔ کمپنی قبول، درجہ بندی، یا مسترد کر سکتی ہے؛ واضح قبول یا ونڈو اختتام آخری Closed کو آٹو کلوز متحرک کرتا ہے، جبکہ مسترد ہونا ٹکٹ کو Reopened میں لے جاتا ہے۔ خراب CSAT ریٹنگ (طے شدہ ≤ 2) اپیل راستہ فعال کرتی ہے؛ اگر کمپنی ونڈو کے اندر اپیل جمع کرائے تو ٹکٹ Appealed میں چلا جاتا ہے، بصورتِ دیگر ونڈو اختتام پر بند ہو جاتا ہے۔

8. دوبارہ کھولنا اور اپیل

8.1 دوبارہ کھولنا

دوبارہ کھولنے کی ونڈو (طے شدہ = CSAT ونڈو؛ csat_config میں قابلِ ترتیب) کے اندر، کمپنی نمائندہ (Primary/Admin، یا Filer اگر Primary اجازت دے) وجہ فراہم کر کے Resolved یا Closed ٹکٹ دوبارہ کھول سکتا ہے۔ دوبارہ کھولنا ٹکٹ کو اس کی پچھلی کام کرنے والی حالت (عام طور پر In Progress) میں لوٹاتا ہے اور قابلِ ترتیب اضافی SLA (طے شدہ = اصل حل SLA کا 50%، capped) کے لیے ریذولوشن کلاک دوبارہ شروع کرتا ہے۔ دوبارہ کھولنا فی ٹکٹ (طے شدہ 2) تک محدود ہے تاکہ اس کا غلط استعمال نہ ہو؛ حد سے تجاوز کرنے پر کمپنی کو اپیل کے راستے پر مجبور کیا جاتا ہے۔ ہر دوبارہ کھولنا ایک آڈٹ شدہ ایونٹ ہے۔

8.2 اپیل (CPGRAMS طرز کا دوسرا موقع)

دوبارہ کھولنے کے علاوہ، کمپنی اپیل ونڈو (طے شدہ بندش سے 30 کیلنڈر دن، قابلِ ترتیب) کے اندر Resolved یا Closed ٹکٹ کے خلاف رسمی اپیل دائر کر سکتی ہے۔ اپیل ایک اعلیٰ اتھارٹی سے درخواست کرتی ہے کہ وہ جائزہ لے کہ حل مناسب تھا یا نہیں۔ اپیلز اس درجے سے ایک اوپر والے اگلے نگرانی درجے کو راؤٹ ہوتی ہیں جس نے ٹکٹ بند کیا تھا: اگر ٹکٹ کام کی سطح پر بند ہوا، DG جائزہ لیتا ہے؛ اگر DG کی سرپرستی میں بند ہوا، سیکریٹری جائزہ لیتا ہے؛ اگر سیکریٹری کی سرپرستی میں بند ہوا، SACM/S&ITD سیکریٹری جائزہ لیتا ہے۔ خراب CSAT ریٹنگ (≤ حد) اپیل فارم کو فعال اور پہلے سے بھر دیتی ہے اور اپیل ونڈو کو قابلِ ترتیب مہلت (طے شدہ +15 دن) تک بڑھا دیتی ہے۔

جائزہ لینے والی اتھارٹی یہ کر سکتی ہے:

• اپیل برقرار رکھنا → ٹکٹ In Progress میں واپس (مناسب حل کے لیے دوبارہ کھولا) سیکشن کے لیے ہدایت کے ساتھ۔
• اپیل مسترد کرنا → ٹکٹ Closed (آخری) رہتا ہے؛ مسترد نامہ (ماڈیول L) QR تصدیق کے ساتھ تیار کر کے کمپنی کو بھیجا جاتا ہے۔
• جزوی برقراری → مخصوص ایکشن آئٹمز ذیلی ٹاسکس کے طور پر شامل کیے جاتے ہیں، ٹکٹ صرف ان آئٹمز کے لیے In Progress میں واپس آتا ہے۔
• دوبارہ راؤٹ → ٹکٹ کسی مختلف سیکشن/محکمے کے تفویض کے لیے Triaged میں چلا جاتا ہے۔

ہر اپیل فیصلہ اداکار، درجہ، استدلال، اور نتیجے کے عمل کے ساتھ آڈٹ ہوتا ہے۔

8.3 دوبارہ کھولنے اور اپیل کا ڈایاگرام

تحریری وضاحت۔ Resolved یا Closed سے کمپنی کے پاس اپنی اپنی ونڈوز کے اندر دو راستے ہیں۔ دوبارہ کھولنے کا راستہ (طے شدہ ونڈو = CSAT ونڈو) کمپنی سے ایک وجہ قبول کرتا ہے اور، فی ٹکٹ دوبارہ کھولنے کی حد (طے شدہ 2) کے تابع، ٹکٹ کو اس کی پچھلی In Progress حالت میں کم SLA (طے شدہ اصل کا 50%) کے ساتھ لوٹاتا ہے۔ جب دوبارہ کھولنے کی حد سے تجاوز ہو تو کمپنی کو اپیل کے راستے پر مجبور کیا جاتا ہے۔ اپیل کا راستہ (بندش سے طے شدہ 30 دن کی ونڈو، خراب CSAT مہلت سے قابلِ توسیع) معاملے کو اس درجے سے ایک اوپر والے اگلے نگرانی درجے پر راؤٹ کرتا ہے جس نے اسے بند کیا تھا۔ جائزہ لینے والی اتھارٹی برقرار رکھ سکتی ہے (ٹکٹ ہدایت کے ساتھ In Progress میں واپس)، جزوی برقرار رکھ سکتی ہے (ذیلی ٹاسکس بنائے جاتے ہیں، ٹکٹ ان آئٹمز کے لیے In Progress میں واپس)، مسترد کر سکتی ہے (بندش حتمی ہے؛ ایک QR تصدیق شدہ مسترد نامہ تیار کیا جاتا ہے)، یا دوبارہ راؤٹ کر سکتی ہے (ٹکٹ مختلف سیکشن کے لیے Triaged میں چلا جاتا ہے)۔ تمام فیصلے آڈٹ ہوتے ہیں۔

9. TRI (سہ فریقی) میٹنگ کا بہاؤ

9.1 TRI کب استعمال ہوتا ہے

ایک TRI (سہ فریقی جائزہ) میٹنگ اس وقت متحرک ہوتی ہے جب عام ٹکٹ پیش رفت رک جائے۔ درج ذیل میں سے کوئی بھی اس کی درخواست کر سکتا ہے:

• کمپنی نمائندہ (ٹکٹ پر "Request TRI meeting" ایکشن)۔
• تفویض شدہ محکمے کا افسر یا سیکشن ہیڈ۔
• S&ITD سہولت کار۔
• SLA انجن کی طرف سے خودکار متحرک جب ٹکٹ درجہ ≥ 2 پر Escalated ہو اور قابلِ ترتیب مدت (طے شدہ 3 کاروباری دن) تک کوئی حرکت نہ ہو۔

ایک TRI درخواست ٹکٹ کو On Hold (کلاک رکتا ہے) وجہ "TRI meeting requested" کے ساتھ لے جاتی ہے اور ٹکٹ سے منسلک TRI قسم کی ایک meetings ریکارڈ بناتی ہے۔

9.2 فریقین اور طریقہ

تین لازمی فریقین یہ ہیں:

1. کمپنی — بنیادی مجاز نمائندہ (یا مندوب)، اختیاری طور پر وکیل/تکنیکی عملے کے ساتھ۔
2. S&ITD — تفویض شدہ سہولت کار، جو میٹنگ کی صدارت کرتا ہے۔
3. متعلقہ محکمہ/محاکم — تفویض شدہ افسر plus سیکشن ہیڈ؛ کثیر المحاکم ٹکٹس کے لیے تمام متعلقہ محاکم۔

طریقہ فی میٹنگ قابلِ ترتیب ہے: فزیکل (محکمے یا S&ITD آفس پر)، ورچوئل (Zoom / Google Meet / Microsoft Teams — فراہم کنندہ فی میٹنگ مرتب کردہ کنیکٹرز سے منتخب کیا جاتا ہے)، یا ہائبرڈ۔ ریکارڈنگ کی رضامندی کسی بھی ریکارڈنگ شروع ہونے سے پہلے حاصل کی جاتی ہے اور meeting_consent میں لاگ کی جاتی ہے۔

9.3 ایجنڈے کی خودکار مسودہ سازی

TRI کی تخلیق پر AI (ماڈیول E) ٹکٹ کی مکمل ہسٹری — عنوان، تفصیل، تمام پیغامات، منسلکات، SLA ایونٹس، پچھلی اسکیلیشنز، اور کوئی متعلقہ ٹکٹس — سے ایجنڈا خودکار تیار کرتا ہے اور مباحثے کے آئٹمز، فیصلے کے نکات، اور تجویز کردہ ترتیب تجویز کرتا ہے۔ سہولت کار دعوت نامے بھیجنے سے پہلے ایجنڈے کا جائزہ لیتا اور ترمیم کرتا ہے۔ ایجنڈا شرکاء کی ترجیح کے مطابق کثیر لسانی (EN/UR/SD) ہوتا ہے۔

9.4 نتیجہ

میٹنگ کے اختتام پر سہولت کار نتیجہ درج ذیل میں سے ایک کے طور پر ریکارڈ کرتا ہے:

• حل شدہ — اتفاق حاصل ہوا؛ ٹکٹ صرف متفقہ ثبوت منسلک کرنے کے لیے In Progress میں واپس آتا ہے، پھر Resolved میں چلا جاتا ہے (ثبوت گیٹ اب بھی لاگو — عام طور پر MoM + دستخط شدہ اتفاق ثبوت کے طور پر)۔
• مزید ایکشن آئٹمز — مخصوص مالکان اور آخری تاریخیں ریکارڈ کی گئیں؛ یہ ذیلی ٹاسکس (§11) بن جاتے ہیں اور ٹکٹ In Progress میں واپس آتا ہے۔
• اسکیلیٹ — میٹنگ مسئلہ حل نہ کر سکی؛ ٹکٹ میٹنگ ریکارڈ کے ساتھ معاون سیاق کے طور پر اگلے درجے پر Escalated میں چلا جاتا ہے۔

تمام صورتوں میں ایک MoM تیار کی جاتی ہے (§10) اور مستقل طور پر ٹکٹ سے منسلک ہو جاتی ہے۔

9.5 TRI بہاؤ ڈایاگرام

تحریری وضاحت۔ جب ٹکٹ رک جائے یا اسکیلیشن درجہ 2+ پر بغیر حرکت بیٹھے، تو کمپنی، افسر، سہولت کار، یا آٹو ٹرگر میں سے کوئی بھی TRI میٹنگ کی درخواست کر سکتا ہے۔ درخواست ایک meetings ریکارڈ بناتی ہے اور ٹکٹ کو وجہ "TRI meeting requested" کے ساتھ On Hold میں کھڑی کرتی ہے، جس سے SLA کلاک رک جاتا ہے۔ AI ٹکٹ کی مکمل ہسٹری اور اپ لوڈز سے ایجنڈا خودکار تیار کرتا ہے، جس کا سہولت کار جائزہ لیتا اور ترمیم کرتا ہے۔ طریقہ — فزیکل، ورچوئل (Zoom/Meet/Teams)، یا ہائبرڈ — فی میٹنگ منتخب کیا جاتا ہے، دعوت نامے کثیر لسانی طور پر بھیجے جاتے ہیں، اور ریکارڈنگ رضامندی حاصل کی جاتی ہے۔ میٹنگ کے بعد، سہولت کار نتیجہ ریکارڈ کرتا ہے: مکمل حل شدہ معاملہ صرف MoM اور دستخط شدہ اتفاق کو ثبوتِ گیٹ ثبوت کے طور پر منسلک کرنے کے لیے In Progress میں واپس آتا ہے، پھر Resolved میں چلا جاتا ہے؛ جزوی نتیجہ مالکان اور آخری تاریخوں کے ساتھ ذیلی ٹاسکس بناتا ہے اور ٹکٹ In Progress میں واپس آتا ہے؛ اتفاق نہ ہونے کی صورت میں ٹکٹ منسلک میٹنگ ریکارڈ کے ساتھ اگلے درجے پر اسکیلیٹ ہو جاتا ہے۔ ہر صورت میں ایک MoM §10 کے مطابق تیار اور منسلک ہوتی ہے۔

10. MoM (اجلاس کی روداد) کا بہاؤ

MoM کا بہاؤ کسی ٹکٹ سے منسلک کسی بھی میٹنگ پر لاگو ہوتا ہے — ایک TRI (§9)، براہِ راست کمپنی-محکمہ میٹنگ، یا کوئی اور ریکارڈ شدہ میٹنگ۔ MoM تیار کرنے والا محکمہ اپنا ہی فارمیٹ اپ لوڈ کرتا ہے (PDF، Word، یا دستخط شدہ کاغذی MoM کی تصاویر)؛ دستی اندراج اور AI لائیو ٹرانسکرپشن فیچر فلیگ شدہ متبادل کے طور پر دستیاب ہیں لیکن پہلے اپ لوڈ _context.md §5 کے مطابق طے شدہ اور بنیادی راستہ ہے۔

10.1 اپ لوڈ → سکین → اسٹور → افزود

1. تیار کریں اور اپ لوڈ کریں۔ محکمے کا افسر یا S&ITD سہولت کار MoM محکمے کے اپنے ٹیمپلیٹ میں تیار کرتا اور اپ لوڈ کرتا ہے (PDF/DOCX/PNG/JPEG)۔ متعدد فائلز کی اجازت ہے۔
2. AV سکین۔ ClamAV ہر اپ لوڈ سکین کرتا ہے؛ متاثر فائلز کو قرنطینہ کیا جاتا ہے اور وجہ کے ساتھ اپ لوڈ مسترد کر دیا جاتا ہے۔
3. اسٹور۔ صاف فائلز خفیہ کی جاتی ہیں اور آبجیکٹ اسٹوریج (MinIO) میں محفوظ کی جاتی ہیں؛ ایک mom_documents قطار بنائی جاتی ہے جو فائل کو meetings ریکارڈ اور پیرنٹ ٹکٹ سے منسلک کرتی ہے۔
4. OCR (اگر سکینڈ ہو)۔ صرف تصویر والی یا سکینڈ PDFs کو پلگ ایبل OCR انجن (Tesseract آن پریم / Google Document AI / Azure Document Intelligence / AWS Textract) کے ذریعے راؤٹ کیا جاتا ہے۔ OCR کثیر لسانی متن (انگریزی + اردو + سندھی، بشمول nastaliq اور naskh اسکرپٹس) کی حمایت کرتا ہے اور قابلِ تلاش متن کی تہہ تیار کرتا ہے۔
5. AI نکالنا۔ AI سروس (ماڈیول E) OCR متن (یا پیدائشی ڈیجیٹل فائلز کے لیے اصل متن) پڑھتی ہے اور نکالتی ہے:
   • میٹنگ کا ایک منظم خلاصہ۔
   • مالک، آخری تاریخ، ترجیح، اور انحصار کے ساتھ ایکشن آئٹمز۔
   • ریکارڈ کردہ فیصلے۔
   • شرکاء (مدعو فہرست سے مشتق)۔
   • EN/UR/SD میں ایک مشین ترجمہ تاکہ شرکاء MoM اپنی پسندیدہ زبان میں پڑھ سکیں۔
6. افسر کا جائزہ اور توثیق۔ اپ لوڈ کرنے والا افسر نکالے گئے ایکشن آئٹمز کا سائیڈ بائی سائیڈ منظر (اصل دستاویز ↔ نکالا ہوا ٹیبل) میں جائزہ لیتا ہے، غلط نکالنے کو درست کرتا ہے، اور توثیق کرتا ہے۔ توثیق شدہ ایکشن آئٹمز پیرنٹ ٹکٹ پر ذیلی ٹاسکس بن جاتے ہیں (§11)، ہر ایک کا اپنا مالک، آخری تاریخ، اور SLA حصہ۔

10.2 منظوری کا گیٹ

• عام ٹکٹ: اپ لوڈر براہِ راست شائع کرتا ہے۔ کوئی منظوری درکار نہیں۔
• حساس / VIP ٹکٹ: MoM کو شائع/شیئر ہونے سے پہلے Chair/DG منظوری سے گزرنا ہوتا ہے۔ MoM منظوری قطار میں داخل ہوتی ہے؛ منظوری پر یہ قابلِ اشاعت ہوتی ہے، مسترد ہونے پر جائزہ کار کی وجہ کے ساتھ اپ لوڈر کے پاس واپس آتی ہے۔

10.3 شائع کریں اور شیئر کریں

شائع ہونے پر:

• MoM ٹکٹ سے مستقل طور پر منسلک ہوتی ہے (ورژن شدہ — ہر ترمیم ایک نئی mom_documents ورژن قطار بناتی ہے؛ پچھلے ورژن برقرار اور آڈٹ لاگ رکھے جاتے ہیں، کبھی اوور رائٹ نہیں)۔
• MoM تمام شرکاء کو خودکار شیئر ہوتی ہے (کمپنی نمائندے، S&ITD سہولت کار، محکمے کے شرکاء، نگرانی ناظرین) اس کے ذریعے:
  • MoM منسلک (یا محفوظ ڈاؤن لوڈ لنک) کے ساتھ ای میل۔
  • ٹکٹ تک ڈیپ لنک کے ساتھ ان-ایپ نوٹیفکیشن۔
  • SMS / واٹس ایپ مختصر خلاصہ + لنک (فی شرکاء ترجیح)۔
• اعتراف ٹریکنگ: ہر شرکے کا اعتراف (کھولنا، ڈاؤن لوڈ، واضح اعتراف) MoM کے خلاف ریکارڈ کیا جاتا ہے اور ٹکٹ ٹائم لائن میں دکھایا جاتا ہے۔ قابلِ ترتیب مہلت (طے شدہ 3 دن) سے زیادہ غیر اعترافی ایک یاد دہانی متحرک کرتا ہے۔
• اگر اس محکمے کے لیے e-Office انٹیگریشن فعال ہو تو MoM NITB e-Office پر کراس پوسٹ کی جاتی ہے (ماڈیول H)، جو متعلقہ سرکاری فائل موومنٹ بناتی ہے۔

10.4 MoM بہاؤ ڈایاگرام

تحریری وضاحت۔ کسی بھی میٹنگ کے بعد، ذمہ دار افسر MoM محکمے کے اپنے فارمیٹ (PDF، Word، یا دستخط شدہ کاغذی دستاویز کی تصاویر) میں اپ لوڈ کرتا ہے۔ ہر اپ لوڈ ClamAV سکین ہوتی ہے؛ صاف فائلز خفیہ کی جاتی ہیں اور میٹنگ اور پیرنٹ ٹکٹ سے منسلک mom_documents قطار کے طور پر محفوظ کی جاتی ہیں۔ سکین شدہ دستاویزات پلگ ایبل کثیر لسانی OCR انجن (انگریزی، اردو بشمول nastaliq، اور سندھی بشمول naskh) سے گزرتی ہیں تاکہ متن کی تہہ تیار ہو؛ پیدائشی ڈیجیٹل فائلز OCR کو چھوڑ دیتی ہیں۔ پھر AI سروس خلاصہ، مالکان اور آخری تاریخوں کے ساتھ منظم ایکشن آئٹمز، ریکارڈ کردہ فیصلے، اور شرکاء کی فہرست نکالتی ہے، اور تینوں زبانوں میں مشین ترجمے تیار کرتی ہے۔ اپ لوڈ کرنے والا افسر نکالنے کا اصل کے ساتھ سائیڈ بائی سائیڈ جائزہ لیتا اور توثیق کرتا ہے؛ توثیق شدہ ایکشن آئٹمز ٹکٹ پر ذیلی ٹاسکس بن جاتے ہیں۔ عام ٹکٹس کے لیے افسر براہِ راست شائع کرتا ہے؛ حساس/VIP ٹکٹس کے لیے MoM کو پہلے Chair/DG منظوری سے گزرنا ہوتا ہے۔ شائع ہونے پر MoM ورژن شدہ اور مستقل طور پر منسلک ہوتی ہے (غیر تبدیل شدہ، پچھلے ورژن برقرار)، تمام شرکاء کو ان کی ترجیحات کے مطابق ای میل، ان-ایپ، اور SMS/واٹس ایپ کے ذریعے خودکار شیئر کی جاتی ہے، اعتراف ٹریک کیے جاتے ہیں اور مہلت کے بعد یاد دہانی بھیجی جاتی ہے۔ اگر محکمے کے پاس e-Office انٹیگریشن فعال ہو، تو MoM سرکاری فائل موومنٹ کے طور پر NITB e-Office پر کراس پوسٹ کی جاتی ہے۔

11. کثیر المحاکم ہم آہنگی

11.1 ریفرل اور متوازی راؤٹنگ

ایک ہی ٹکٹ میں متعدد محاکم شامل ہو سکتے ہیں۔ دو راؤٹنگ موڈز معاون ہیں اور مل بھی سکتے ہیں:

• متوالی ریفرل — لیڈ محکمہ اپنا حصہ حل کرتا ہے پھر ٹکٹ آگے ریفر کرتا ہے (مثلاً SECP NTN درستگی کے لیے FBR کو ریفر کرتا ہے)۔ ٹکٹ کی کام کرنے والی حالت فی محکمہ محفوظ رہتی ہے؛ اگلے کے انتظار میں ریفرنگ محکمے کے لیے SLA کلاکیں رک جاتی ہیں۔
• متوازی راؤٹنگ — ایک ٹکٹ متعدد محاکم کی طرف سے بیک وقت کام ہوتا ہے، ہر ایک کا اپنا ذیلی ٹاسک اور اپنا SLA حصہ۔ پیرنٹ ٹکٹ اس وقت تک Resolved نہیں پہنچ سکتا جب تک تمام ذیلی ٹاسکس حل نہ ہوں یا لیڈ محکمے کی طرف سے واضح معاف نہ کیے جائیں (ثبوت گیٹ پیش شرط §7.1)۔

ہر راؤٹڈ محکمے کو اپنی تفویض، sla_definitions سے اپنی SLA قطار، اور escalation_ladders سے اپنا اسکیلیشن لیڈر ملتا ہے۔ S&ITD سہولت کار کو بین المحاکم نظر انداز حاصل ہے اور وہ کسی بھی وقت دوبارہ توازن، ضم، یا تقسیم کر سکتا ہے۔

11.2 ذیلی ٹاسکس

ذیلی ٹاسک parent_ticket_id کے ذریعے منسلک ایک مکمل ٹکٹ ہوتا ہے۔ ذیلی ٹاسکس طے شدہ طور پر پیرنٹ سے زمرہ، ترجیح، اور SLA ورثے میں حاصل کرتے ہیں لیکن اوورائیڈ کیے جا سکتے ہیں۔ ذیلی ٹاسکس کی اپنی حیثیت لائف سائیکل (§2)، اپنے SLA کلاکس، اور اپنے اسکیلیشن لیڈرز ہوتے ہیں۔ MoM ایکشن آئٹمز (§10) سے بننے والے ذیلی ٹاسکس origin = mom_action_item MoM کے حوالے کے ساتھ رکھتے ہیں۔ پیرنٹ ٹکٹ کا حل تمام لازمی ذیلی ٹاسکس کے حل پر مبنی ہوتا ہے۔

11.3 لنک / متعلق / ضم / تقسیم

11.4 بلک ایکشنز

مجاز اداکار (سہولت کار، سیکشن ہیڈ، عمل کے اختیارات والے DG/سیکریٹری) ٹکٹس کے فلٹر شدہ انتخاب پر بلک آپریشنز کر سکتے ہیں: بلک تفویض، بلک دوبارہ راؤٹ، بلک روک (On Hold)، بلک ضم، بلک کلوز (وجہ کے ساتھ)، بلک ناظر شامل، بلک ایکسپورٹ۔ ہر بلک ایکشن قابلِ تتبعیت کے لیے بلک ایکشن آئی ڈی کے ساتھ ہر متاثر ٹکٹ پر ایک مرتبہ audit_events میں لاگ ہوتا ہے۔

11.5 کثیر المحاکم ہم آہنگی ڈایاگرام

تحریری وضاحت۔ S&ITD سہولت کار کی طرف سے پیرنٹ ٹکٹ کو یا تو متوالی (SECP → FBR → SRB کے ذریعے ریفرل چین، جس میں ہر محکمے کی SLA کلاک صرف اپنی باری کے دوران چلتی ہے) یا متوازی طور پر (متوازی ذیلی ٹاسکس، ہر ایک کا اپنا SLA اور اسکیلیشن لیڈر، جن میں سے سب کو پیرنٹ کے ثبوت گیٹ سے گزرنے سے پہلے حل ہونا چاہیے) راؤٹ کیا جا سکتا ہے۔ ذیلی ٹاسکس parent_ticket_id سے منسلک مکمل ٹکٹس ہیں؛ MoM ایکشن آئٹمز سے نکلنے والے متعلقہ ٹیگ رکھتے ہیں۔ لنک/متعلق دونوں آزاد ٹکٹس کو ان کے لائف سائیکل ضم کیے بغیر جوڑتا ہے؛ ضم کرنا نقل کو مستند ٹکٹ میں ضم کرتا ہے اور مکمل ہسٹری محفوظ رکھنے کے ساتھ باقی کو منسوخ کرتا ہے؛ تقسیم کرنا ایک فائلنگ میں اٹھائے گئے الگ مسائل کے لیے نئی ٹریکنگ آئی ڈیز بناتا ہے۔ ناظرین اور CC تفویض بدلے بغیر مشاہدین شامل کرتے ہیں۔ بلک ایکشنز مجاز اداکاروں کو فلٹر شدہ انتخابوں پر تبدیلیاں لاگو کرنے دیتے ہیں، جس میں ہر متاثر ٹکٹ ایک مشترکہ بلک ایکشن آئی ڈی کے تحت انفرادی طور پر آڈٹ ہوتا ہے۔

12. ہر تبدیلی پر نوٹیفکیشنز

نوٹیفکیشن سروس (ماڈیول G) ہر آڈٹ شدہ تبدیلی پر ٹیمپلیٹ شدہ، کثیر لسانی نوٹیفکیشنز بھیجتی ہے۔ ہر نوٹیفکیشن کی زبان وصول کنندہ کی پسندیدہ زبان ہوتی ہے؛ ہر چینل وصول کنندہ کے پسندیدہ مرکز (ڈائجسٹس، خاموش اوقات، چینل آپٹ ان) کا احترام کرتا ہے۔ دو طرفہ آنے والے جوابات — نوٹیفکیشن ای میل یا واٹس ایپ کا جواب — پارس کیے جاتے ہیں اور تھریڈنگ کے لیے اصل نوٹیفکیشن کے حوالے کے ساتھ ٹکٹ پر بطور آنے والا پیغام منسلک کیے جاتے ہیں۔

تمام ٹیمپلیٹس ورژن شدہ اور سپر ایڈمن (فی زبان) کی طرف سے قابلِ ترمیم ہیں۔ ہر بھیجا گیا نوٹیفکیشن خود ٹیمپلیٹ آئی ڈی، زبان، چینل، وصول کنندہ، اور ترسیل کی حیثیت کے ساتھ notifications میں لاگ ہوتا ہے، اور آڈٹ کے لیے برقرار رکھا جاتا ہے۔

13. آڈٹ اور تتبعیت

ہر حالت کی تبدیلی، اسکیلیشن، روک، دوبارہ شروع، منظوری، شائع، ضم، تقسیم، بلک ایکشن، اور نوٹیفکیشن دو متکمل اسٹورز میں غیر تبدیل شدہ طور پر ریکارڈ کی جاتی ہے (ڈیٹا ماڈل /specs/ur/05-data-model/ میں):

• ticket_history — انسان کے پڑھنے کے قابل، ٹکٹ تک محدود ٹائم لائن۔ فی تبدیلی ایک قطار ticket_id، from_status، to_status، actor_id، actor_role، timestamp، reason، اور بدلی فیلڈز کے diff کے ساتھ۔
• audit_events — سسٹم تک محدود، صرف اضافے والا ایونٹ لاگ۔ فی قابلِ آڈٹ ایکشن ایک قطار event_type (state_change، escalation، sla_pause، sla_resume، sla_override، approval_decision، mom_publish، merge، split، bulk_action، notification_sent، …)، actor_id، actor_role، target_type، target_id، payload (JSON)، ip، user_agent، timestamp، اور اختیاری reason کے ساتھ۔

دونوں ٹیبلز میں قطاریں صرف اضافے والی ہیں؛ ایپلیکیشن یا DB-role سطح پر کوئی UPDATE یا DELETE کی اجازت نہیں (MariaDB گرانٹس کے ذریعے نافذ — /specs/ur/11-security-compliance/ دیکھیں)۔ ایک علیحدہ رٹینشن/آرکائول کام سندھ آرکائوز کے قواعد کے مطابق (_context.md کے §6) پرانی قطاروں کو کولڈ اسٹوریج میں منتقل کرتا ہے بغیر انہیں حذف کیے۔

ہر audit_events قطار کا کراس ریفرنس ہوتا ہے:

• مشترکہ correlation_id کے ذریعے اصل ticket_history قطار سے۔
• notifications.audit_event_id کے ذریعے بھیجے گئے کسی بھی نوٹیفکیشن (§12) سے۔
• payload.file_ids / payload.mom_id کے ذریعے شامل کسی بھی فائل یا MoM سے۔

یہ "کمپنی نے T0 پر دائر کیا" سے ہر ٹرائج، روک، اسکیلیشن، منظوری، MoM شائع، اور بندش تک سرے سے آخر تتبعیت فراہم کرتا ہے — جو اندرونی گورننس جائزہ اور بیرونی آڈٹ (RTI، آڈیٹر جنرل، CERT-PK) دونوں کو مطمئن کرتا ہے۔

14. غیر معمولی معاملات

15. قابلِ ترتیب کا خلاصہ

سسٹم اس طرح ڈیزائن کیا گیا ہے کہ تقریباً ہر رویے کا پیرامیٹر قابلِ ترتیب ہے، یا تو عالمی طور پر (S&ITD-پھیلا ہوا) یا فی محکمہ/زمرہ۔ نیچے کا میٹرکس خلاصہ کرتا ہے کہ کیا قابلِ ترتیب ہے اور کہاں رہتا ہے۔ ◐ سے نشان زد سیلز مشروط ہیں (جہاں اشارہ کیا گیا ہے وہاں قابلِ ترتیب)۔

کنفیگریشن گورننس۔ تمام کنفیگریشن ٹیبلز خود آڈٹ ہوتے ہیں: sla_definitions، escalation_ladders، oversight_powers، dept_business_hours، holiday_calendar، csat_config، appeal_config، tri_config، mom_config، یا feature_flags کسی بھی قطار میں تبدیلی ایک audit_events اندراج پرانا اور نیا قیمت، اداکار، اور لازمی تبدیلی وجہ کے ساتھ لکھتی ہے۔ کنفیگریشن تبدیلیاں عالمی قطاروں کے لیے سپر ایڈمن (S&ITD) تک اور محکمے تک محدود قطاروں کے لیے محکمے کے DG/سیکریٹری (عمل کے اختیارات کے ساتھ) تک محدود ہیں۔ حساس عالمی تبدیلیاں (مثلاً ثبوت گیٹ کو غیر فعال کرنا) دو افراد کی منظوری کا تقاضا کرتی ہیں۔

دستاویز کا اختتام۔