اجلاسات، TRI اور اجلاس کی روداد

کسی ٹکٹ سے منسلک تمام اجلاسات — سہ فریقی (TRI) جائزے، سماعت، محکماتی اور براہِ راست اجلاس، اور سائٹ وزٹس — اور اپلوڈ-فرسٹ اجلاس کی روداد (MoM) لائف سائیکل، اے آئی نکالنے کے عمل، منظوری کے دروازے، اشاعت و خودکار اشتراک، اور سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) پر تجزیات کے لیے مستند تفصیلات۔

1. دائرہ کار و تعریفات

یہ دستاویز ماڈیول M کے لیے اکیلا مستند ماخذ ہے۔ اس میں ہر اس قسم کے اجلاس کی تعریف ہے جو کسی ٹکٹ سے منسلک ہو سکتا ہے، اجلاس کیسے شیڈول کیے جاتے ہیں، ان کی رودادیں کیسے تیار اور شیئر کی جاتی ہیں، اور روداد کے اندر موجود ایکشن آئٹمز کس طرح ذیلی ٹاسک کے طور پر ٹکٹ میں واپس بہتے ہیں۔ یہ /specs/ur/05-data-model/ §4.9 میں تعریف کردہ meetings, meeting_attendees, mom, mom_approvals, mom_distributions, mom_acknowledgments, اور meeting_recordings ٹیبلز کے لیے معیاری حوالہ ہے۔

ٹکٹ لائف سائیکل، SLA، ایسکیلیشن زینہ، ثبوتِ حل کا دروازہ، دوبارہ کھولنے/اپیل کی مدتیں، اور /specs/ur/06-ticket-workflow/ §9–§10 میں موجود TRI/MoM خلاصہ وہیں گورن ہوتے ہیں؛ یہ دستاویز انہیں مکمل ماڈیول-M تفصیلات میں پھیلاتی ہے۔ جہاں دونوں دستاویزات میں فرق معلوم ہوتا ہے، ماڈیول-M کے رویے کے لیے یہ دستاویز ہی مستند ہے اور ٹکٹ-ورک فلو دستاویز اس کے تابع ہے۔

لغت (مختصر صورت؛ دیکھیں _glossary.md):

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

2. اجلاس کی اقسام

کوئی بھی اجلاس ہمیشہ بالکل ایک ہی ٹکٹ سے منسلک ہوتا ہے (meetings.ticket_id فورن کی)۔ ایک ٹکٹ کی زندگی میں متعدد اجلاس ہو سکتے ہیں۔ سسٹم پانچ اقسام کے اجلاس تسلیم کرتا ہے، جو مقصد اور حاضر ہونے والے فریقین کی بنیاد پر درجہ بند ہیں۔ ڈیٹا ماڈل کا meetings.type enum (دیکھیں /specs/ur/05-data-model/ §4.9) فی الحال tri, hearing, internal رکھتا ہے؛ یہ دستاویز مستند درجہ بندی بیان کرتی ہے اور مکمل سیٹ کا احاطہ کرنے کے لیے enum کی توسیع (دیکھیں §12 ڈیٹا-ماڈل خلاصہ) کا تقاضا کرتی ہے، مزید درجہ بندی کے لیے ایک subtype امتیاز کار کے ساتھ۔

اقسام پر مشترکہ قواعد:

• ہر اجلاس بالکل ایک MoM پیدا کرتا ہے (mom.meeting_id میں 1:1، منفرد)۔ سسٹم میں کوئی "بغیر روداد" اجلاس نہیں ہے؛ یہاں تک کہ اندرونی ہم آہنگی کا اجلاس بھی آڈٹ ٹریل کے لیے ایک مختصر MoM پیدا کرتا ہے۔
• ہر اجلاس اپنے ٹکٹ سے مستقل منسلک ہوتا ہے (آڈٹ لاگڈ، غیر تبدیل شدہ ہسٹری)۔ اجلاس منسوخ یا ری شیڈول کرنا اس کا ریکارڈ کبھی حذف نہیں کرتا۔
• پانچوں اقسام ذیل میں بیان کردہ اسی شیڈولنگ، رضامندی، ریکارڈنگ، اشاعت، اور اقرار مشینری شیئر کرتی ہیں؛ وہ مطلوبہ فریقین، کورم قواعد، منظوری روٹنگ، اور اس سامعین میں فرق رکھتی ہیں جس کو MoM شیئر کی جاتی ہے (مثلاً اندرونی MoM کمپنی کو خودکار شیئر نہیں ہوتی)۔

3. شیڈولنگ و کیلنڈر

3.1 کیلنڈر ماڈل

ہر meetings قطار scheduled_at، started_at، ended_at (تمام DATETIME(6)، default Asia/Karachi ٹائم زون)، ایک status enum (§11)، modality، اور جہاں قابل اطلاق ہو video_provider، join_url، اور location_address رکھتی ہے۔ پورٹل ایک فی-صارف کیلنڈر ویو برقرار رکھتا ہے جو ہر اس اجلاس کو جمع کرتا ہے جس میں صارف مدعو ہے، اس کے علاوہ سندھ حکومت کی چھٹیوں کا کیلنڈر اور ہر محکمے کے کاروباری اوقات (دیکھیں /specs/ur/06-ticket-workflow/ §5.4) تاکہ شیڈولنگ دونوں کا احترام کرے۔

3.2 دستیابی اور متصادم چیکس

شیڈولنگ پر، پورٹل تمام مدعو افراد کے کیلنڈرز اور میٹنگ روم / ورچوئل-پرووائیڈر وسائل پر ایک متصادم چیک چلاتا ہے:

• ایک ہارڈ متصادم (کسی مدعو کا پہلے سے scheduled یا in_progress اجلاس تجویز کردہ سلاٹ سے متصادم ہے) اس مدعو کے لیے اس سلاٹ کو بلاک کر دیتا ہے اور ±N کاروباری گھنٹوں کے اندر (default N = 2) متبادل خالی سلاٹس دکھاتا ہے، ہر مدعو کے محکمے کے کاروباری اوقات کا احترام کرتے ہوئے۔
• ایک سافٹ متصادم (کسی مدعو کو کسی دوسرے اجلاس پر "عارضی" نشان زد کیا گیا ہے، یا وہ کاروباری اوقات سے باہر ہے) تنبیہ کرتا ہے مگر بلاک نہیں کرتا۔
• چھٹی چیک کسی بھی اس سلاٹ کو مسترد کرتا ہے جو سندھ کی سرکاری چھٹی پر آتا ہے (holiday_calendar دیکھیں)؛ شیڈولر اگلا کاروباری دن تجویز کرتا ہے۔ ہجری تاریخ کی چھٹیاں (عید، عاشورہ وغیرہ) ہر سال /specs/ur/06-ticket-workflow/ §5.4 کے مطابق گریگورین میں حل کی جاتی ہیں۔
• ویک اینڈ چیک فی-محکمہ ویک اینڈ کنفیگریشن (default ہفتہ + اتوار) کا احترام کرتا ہے۔
• کورم تصدیق۔ TRI اور سماعتوں کے لیے شیڈولر یہ یقینی بناتا ہے کہ مطلوبہ کورم (§7.4) حاصل ہو سکتا ہے: اجلاس کو scheduled سے تصدیق شدہ حالت میں منتقل ہونے سے پہلے ہر لازمی فریق کی طرف سے کم از کم ایک قبولیت درکار ہے۔

3.3 ری شیڈول اور منسوخی

کوئی بھی منتظم (TRI کے لیے S&ITD فیسلیٹیٹر؛ سماعتوں کے لیے بلاتی اتھارٹی؛ اندرونی/براہِ راست کے لیے افسر) کسی scheduled اجلاس کو ری شیڈول یا منسوخ کر سکتا ہے۔

• ری شیڈول نیا scheduled_at لکھتا ہے، متصادم/کورم چیکس دوبارہ چلاتا ہے، اور تمام مدعو افراد کو اپ ڈیٹڈ وقت اور تازہ join_url (presigned، وقت محدود) کے ساتھ مطلع کرتا ہے۔ پچھلا سلاٹ خالی کر دیا جاتا ہے۔ ہر ری شیڈول آڈٹ ہوتا ہے (audit_events.type = meeting_rescheduled)۔
• منسوخی وجہ کے ساتھ meetings.status = cancelled سیٹ کرتی ہے؛ سلاٹ خالی کر دیا جاتا ہے؛ مدعو افراد مطلع کیے جاتے ہیں؛ منسلک mom (اگر پہلے مسودہ تیار ہو گیا ہو) آڈٹ تسلسل کے لیے منسوخی وجہ کے ساتھ draft حالت میں برقرار رکھا جاتا ہے۔ منسوخ شدہ اجلاس کبھی physical حذف نہیں ہوتا۔
• ٹکٹ ٹرمینل پر خودکار منسوخی۔ اگر والد ٹکٹ اجلاس کے scheduled_at سے پہلے ٹرمینل حالت (Closed یا Cancelled/Withdrawn) تک پہنچ جائے، تو پورٹل اجلاس کو خودکار منسوخ کر دیتا ہے اور مدعو افراد کو مطلع کرتا ہے، جب تک کہ منتظم نے واضح طور پر اجلاس کو "بہر حال جاری رکھیں" نشان زد نہ کیا ہو۔

3.4 یاد دہانیاں

یاد دہانیاں تمام شرکاء اور ناظرین کو ان کی ترجیحی چینلز کے ذریعے نوٹیفکیشن ماڈیول (G) کے مطابق بھیجی جاتی ہیں:

یاد دہانی کا وقت اور چینلز meeting_reminder_config میں عالمی اور فی محکمہ کنفیگر ہوتے ہیں (dept_id, type سے کلید کے طور پر)۔

4. طریقہ و ویڈیو پرووائیڈرز

4.1 طریقہ (Modality)

ہر اجلاس تین طریقوں میں سے ایک ہوتا ہے (meetings.modality):

• Physical — کسی مقام پر منعقد؛ location_address لازمی ہے؛ کوئی join_url نہیں۔ ریکارڈنگ (اگر ہو) مخصوص ڈیوائس کے ذریعے؛ رضامندی §10 کے مطابق حاصل کی جاتی ہے۔
• Virtual — مکمل آن لائن کسی ویڈیو پرووائیڈر کے ذریعے منعقد؛ video_provider اور join_url دونوں لازمی ہیں؛ location_address null ہے۔
• Hybrid — کچھ شرکاء physical مقام پر، دیگر ورچوئلی طور پر شامل؛ location_address اور video_provider + join_url دونوں بھرے ہوئے ہیں۔

طریقہ فی اجلاس منتظم کے ذریعے منتخب کیا جاتا ہے اور اجلاس کی قسم سے محدود نہیں ہوتا، دو استثنات کے ساتھ: سائٹ وزٹس (T5) ہمیشہ physical ہوتے ہیں؛ سماعت (T4) physical پر default ہوتی ہیں جب تک بلاتی اتھارٹی واضح طور پر ورچوئل شرکت کی اجازت نہ دے۔

4.2 ویڈیو پرووائیڈرز (فی اجلاس کنفیگرable)

پورٹل تین کنفیگرable ویڈیو پرووائیڈرز — Zoom، Google Meet، اور Microsoft Teams — کو ایک مستحکم انٹرفیس کے پیچھے ضم کرتا ہے۔ پرووائیڈر فی اجلاس منتظم کے ذریعے منتخب کیا جاتا ہے؛ یہ عالمی سیٹنگ نہیں ہے، کیونکہ مختلف محکمے اور افسران کے مختلف معیاری پلیٹ فارمز ہیں۔

علامات _conventions.md §8 کے مطابق۔ ✓ معاون · ◐ مشروط۔

انٹرفیس معاہدہ۔ ہر ویڈیو-پرووائیڈر انٹیگریشن یہ نافذ کرتا ہے:

VideoProvider {
  createMeeting(meeting)        -> { providerMeetingId, joinUrl, hostUrl, dialIn? }
  updateMeeting(meeting)        -> void
  cancelMeeting(meeting)        -> void
  getJoinUrl(meeting, user)     -> presigned, time-limited URL
  fetchRecording(meeting)       -> { mediaId, durationSeconds, format }
  fetchTranscript(meeting)      -> { mediaId, segments: [{speaker, start, end, text}] }
}

پرووائیڈر اسناد سیکریٹ اسٹور میں محفوظ ہیں (دیکھیں /specs/ur/11-security-compliance/) فی (department, provider) کلید کے ساتھ تاکہ ہر محکمہ اپنا tenant استعمال کر سکے۔

اجلاس بنانے پر پورٹل createMeeting کو کال کرتا ہے، واپس ملنے والی providerMeetingId اور وقت محدود join_url (presigned؛ default TTL = شیڈولڈ وقت + 2 گھنٹے) محفوظ کرتا ہے، اور join لنک کو کیلنڈر انوائٹ اور یاد دہانیوں میں شامل کرتا ہے۔ ہر join_url ری شیڈول پر rotate ہوتی ہے۔

اجلاس مکمل ہونے پر (یا اجلاس کے دوران منتظم کی درخواست پر)، پورٹل ریکارڈنگ کھینچنے کے لیے fetchRecording (رضامندی کے تابع — §10) اور اسپیکر لیبل والا ٹرانسکرپٹ کھینچنے کے لیے fetchTranscript کال کر سکتا ہے۔ دونوں media_library blob سے منسلک meeting_recordings قطارات کے طور پر محفوظ ہوتے ہیں (rest میں encrypted)۔ ٹرانسکرپٹ اے آئی ٹرانسکرپشن MoM موڈ (§8.2) کو فیڈ کرتا ہے۔

فال بیک۔ اگر منتخب پرووائیڈر کا API اجلاس-بنانے کے وقت دستیاب نہ ہو، تو پورٹل محکمے کے ثانوی پرووائیڈر پر فال بیک کرتا ہے؛ اگر کوئی دستیاب نہ ہو، تو یہ ایک placeholder بناتا ہے اور منتظم سے manual اجلاس لنک منسلک کرنے کو کہتا ہے۔ کوئی اجلاس صرف اس لیے نہیں روکا جاتا کہ پرووائیڈر API ڈاؤن ہے۔

5. اے آئی تیار کردہ ایجنڈا

ہر اجلاس کے لیے اے آئی (ماڈیول E، صلاحیت summary) والد ٹکٹ کے مکمل سیاق و سباق سے ایک ایجنڈا آٹو تیار کرتا ہے، جو meetings.agenda_json میں محفوظ ہوتا ہے۔ ایجنڈا ایک تجویز ہے؛ فیسلیٹیٹر دعوت نامے بھیجے جانے سے پہلے اس کا جائزہ لیتا اور ترمیم کرتا ہے (ہیومن-ان-دا-لوپ، /specs/ur/07-ai-ocr-spec/ §1.1 کا اصول P2)۔

ایجنڈے کے مداخل:

• ٹکٹ کا عنوان، وضاحت، زمرہ، اور SLA واقعات۔
• مکمل پیغام ہسٹری (PII حذف شدہ)۔
• منسلک OCR متن (ثبوت دستاویزات، پچھلی MoMs، متعلقہ خط و کتابت)۔
• ایسکیلیشن ہسٹری اور ٹکٹ پر کوئی پچھلا TRI نتیجہ۔
• منسلک / ضم / مماثل ٹکٹس (صرف ان کا metadata، ان کی باڈیز نہیں)۔

آؤٹ پٹ ساخت (agenda_json):

ایجنڈا فیسلیٹیٹر کی ترجیحی لوکیل میں جنریٹ ہوتا ہے اور کثیر لسانی دعوت ناموں کے لیے EN/UR/SD میں مشین-ترجمہ ہوتا ہے۔ فیسلیٹیٹر کسی بھی خانے کو override کر سکتا ہے؛ اے آئی مسودہ اور حتمی کے درمیان diff بہتری کے لوپ کے لیے ai_feedback میں لاگ ہوتا ہے۔ سماعتوں (T4) کے لیے ایجنڈا اضافی طور پر قانونی/مargaripe قانونی بنیاد اور ریکارڈ پر لی جانے والی ثبوتوں کی فہرست بھی ظاہر کرتا ہے۔

6. TRI متحرک ہونا و بہاؤ

6.1 جب TRI کی درخواست ہوتی ہے

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

• کمپنی نمائندہ — ٹکٹ پر "Request TRI meeting" ایکشن کے ذریعے (بنیادی/ایڈمن نمائندوں کو نظر آتا ہے؛ Filer اگر بنیادی کی اجازت ہو)۔
• تفویض کردہ محکماتی افسر یا سیکشن ہیڈ۔
• S&ITD فیسلیٹیٹر۔
• خودکار — SLA انجن اس وقت فائر ہوتا ہے جب کوئی ٹکٹ Escalated پر طبقہ ≥ 2 پر configurable وقفے (default 3 کاروباری دن) تک بغیر حرکت کے رہا ہو۔

TRI درخواست والد ٹکٹ کو وجہ "TRI meeting requested" کے ساتھ On Hold (SLA گھڑی رکی) پر منتقل کرتی ہے، type = 'tri' کے ساتھ ایک meetings قطار بناتی ہے، اور تینوں مطلوبہ فریقین کو مطلع کرتی ہے۔ TRI درخواست خود ایک آڈٹ شدہ واقعہ ہے۔

6.2 منعقد کرنے کی منظوریاں

غیر حساس ٹکٹس کے لیے TRI درخواست پر بغیر اضافی منظوری کے منعقد ہو جاتا ہے۔ حساس یا VIP ٹکٹس کے لیے درخواست دعوت نامے بھیجے جانے سے پہلے محکمے کے صدرِ نشین/DG (یا S&ITD DG جہاں S&ITD متعلقہ محکمہ ہو) کی sign-off کے لیے روٹ ہوتی ہے، /specs/ur/06-ticket-workflow/ §7.3 میں ثبوتِ حل کی منظوری logic کو mirror کرتے ہوئے۔

6.3 فریقین اور کورم

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

TRI کے لیے کورم = تینوں فریقین میں سے ہر ایک کا کم از کم ایک نمائندہ۔ اگر scheduled_at کے 30 منٹ بعد کورم مکمل نہیں ہوتا، تو فیسلیٹیٹر یا تو (a) ملتوی اور ری شیڈول کر سکتا ہے، یا (b) جزوی اجلاس کے طور پر جاری رکھ سکتا ہے جس کی MoM واضح طور پر "جزوی — بغیر [party]" نشان زد ہوتی ہے اور پابند فیصلے ریکارڈ نہیں کر سکتی۔

6.4 نتیجہ

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

• حل شدہ — معاہدہ ہو گیا۔ ٹکٹ صرف متفقہ ثبوت (عام طور پر sign شدہ MoM اور کوئی تصفیہ/معاہدہ) منسلک کرنے کے لیے In Progress پر واپس آتا ہے، پھر ثبوتِ حل کے دروازے (/specs/ur/06-ticket-workflow/ §7) سے Resolved میں منتقل ہوتا ہے۔
• مزید ایکشن آئٹمز — مخصوص مالکان اور due تاریخیں ریکارڈ کی جاتی ہیں؛ یہ ٹکٹ ذیلی ٹاسک (§9.6) بن جاتے ہیں اور ٹکٹ In Progress پر واپس آتا ہے۔
• ایسکیلیٹ — اجلاس مسئلہ حل نہیں کر سکا۔ ٹکٹ اجلاس ریکارڈ کو context کے طور پر لے کر اگلے نگرانی طبقے پر Escalated میں منتقل ہوتا ہے۔
• ملتوی — کورم مکمل نہیں ہوا، یا مزید معلومات/وقت درکار ہے۔ ٹکٹ On Hold رہتا ہے؛ ایک follow-up TRI شیڈول ہوتی ہے۔

ہر صورت میں ایک MoM تیار ہوتی ہے اور §9 کے مطابق مستقل منسلک ہوتی ہے۔

6.5 TRI بہاؤ خاکہ

تحریری وضاحت۔ TRI اس وقت شروع ہوتا ہے جب کوئی ٹکٹ رک جائے یا ایسکیلیشن طبقہ 2 یا اس سے اوپر بغیر حرکت کے رہے۔ کمپنی، افسر، فیسلیٹیٹر، یا SLA-انجن آٹو-ٹرگر میں سے کوئی بھی اس کی درخواست کر سکتا ہے؛ درخواست tri قسم کی ایک meetings قطار بناتی ہے اور وجہ "TRI meeting requested" کے ساتھ ٹکٹ کو On Hold میں پارک کرتی ہے، SLA گھڑی روکتی ہے۔ حساس یا VIP ٹکٹس کے لیے درخواست پہلے sign-off کے لیے صدرِ نشین/DG کے پاس جاتی ہے؛ مسترد ہونے پر ٹکٹ وجہ ریکارڈ کے ساتھ On Hold رہتا ہے۔ اے آئی ٹکٹ ہسٹری اور اپلوڈز سے ایجنڈا آٹو تیار کرتا ہے، جس کا فیسلیٹیٹر جائزہ لیتا اور ترمیم کرتا ہے۔ طریقہ فی اجلاس منتخب ہوتا ہے — physical (مقام بُک)، virtual (Zoom/Meet/Teams اجلاس بنا اور join_url جنریٹ ہوا)، یا hybrid (دونوں)۔ کثیر لسانی دعوت نامے بھیجے جاتے ہیں اور کسی بھی ریکارڈنگ کے شروع ہونے سے پہلے ریکارڈنگ رضامندی حاصل کی جاتی ہے۔ شیڈولڈ وقت پر کورم چیک ہوتا ہے؛ اگر مکمل نہ ہو، تو فیسلیٹیٹر ملتوی اور ری شیڈول کرتا ہے۔ کورم مکمل ہونے پر اجلاس جاری رہتا ہے اور فیسلیٹیٹر چار نتائج میں سے ایک ریکارڈ کرتا ہے: حل شدہ (ٹکٹ ثبوت کے طور پر MoM اور sign شدہ معاہدہ منسلک کرنے کے لیے مختصراً In Progress پر واپس آتا ہے، پھر Resolved میں منتقل ہوتا ہے)؛ مزید ایکشن آئٹمز (ایکشن آئٹمز ذیلی ٹاسک کے طور پر تصدیق ہوتے ہیں، ٹکٹ In Progress پر واپس آتا ہے)؛ ایسکیلیٹ (ٹکٹ اجلاس ریکارڈ کو context کے طور پر اگلے ایسکیلیشن طبقے پر منتقل ہوتا ہے)؛ یا ملتوی (follow-up TRI شیڈول ہوتی ہے، ٹکٹ On Hold رہتا ہے)۔ ہر صورت میں ایک MoM تیار ہوتی ہے اور §9 کے مطابق مستقل منسلک ہوتی ہے۔

7. شرکاء و کردار

7.1 شرکاء کا ریکارڈ

اجلاس میں حاضر (یا مدعو) ہر شخص meeting_attendees میں ریکارڈ ہوتا ہے، ایک party (company, sitd, department, external) اور free-text role کے ساتھ ٹیگ شدہ۔ اندرونی شرکاء users.id سے منسلک ہوتے ہیں؛ بیرونی شرکاء (counsel، کنسلٹنٹس، سماعت میں عام افراد) صرف نام سے ریکارڈ ہوتے ہیں۔

7.2 کردار

7.3 حاضری حالت لائف سائیکل

ہر meeting_attendees قطار invited → accepted | declined → attended | absent سے گزرتی ہے۔ accepted شمار شیڈولنگ میں کورم تصدیق (§3.2) کو چلاتا ہے۔

7.4 قسم کے مطابق کورم قواعد

کورم قواعد meeting_quorum_config میں فی (department, type) کنفیگر ہوتے ہیں۔

8. MoM لائف سائیکل (اپلوڈ-فرسٹ)

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

8.1 اپلوڈ-فرسٹ لائف سائیکل

1. تیار اور اپلوڈ۔ اجلاس کے بعد، مخصوص نوٹ لینے والا (عام طور پر محکمے کا افسر، بعض اوقات فیسلیٹیٹر) محکمے کے اپنے ٹیمپلیٹ میں MoM تیار کرتا اور اپلوڈ کرتا ہے (PDF/DOCX/PNG/JPEG؛ متعدد فائلز کی اجازت)۔ اپلوڈ اجلاس اور والد ٹکٹ سے منسلک ہوتا ہے۔
2. AV اسکین۔ ClamAV ہر اپلوڈ اسکین کرتا ہے (ماڈیول D)۔ متاثر فائلز quarantine ہوتی ہیں اور اپلوڈ وجہ audit_events میں لاگ کے ساتھ مسترد ہوتا ہے۔
3. محفوظ۔ صاف فائلز encrypted اور moms bucket کے تحت MinIO میں محفوظ ہوتی ہیں؛ ایک mom.source_media_id حوالہ سیٹ ہوتا ہے اور ایک mom قطار بنائی جاتی ہے (یا اگر پچھلا مسودہ موجود ہو تو اس کا source_media_id اپ ڈیٹ ہوتا ہے)۔
4. OCR (اگر scanned)۔ صرف تصویر والی یا scanned PDFs pluggable OCR انجن (on-prem Tesseract / Google Document AI / Azure Document Intelligence / AWS Textract) سے /specs/ur/07-ai-ocr-spec/ §3.2 اور §4.1 کے مطابق گزرتی ہیں۔ OCR کثیر لسانی (EN + UR + Sindhi، Nastaliq اور Naskh scripts سمیت) ہے اور confidence scores کے ساتھ searchable متن کی تہہ پیدا کرتا ہے؛ کم-confidence spans جائزے کے لیے flag ہوتی ہیں۔
5. اے آئی نکالنا۔ اے آئی سروس (ماڈیول E، صلاحیت mom_extract، /specs/ur/07-ai-ocr-spec/ §4.11) OCR متن (یا born-digital فائلز کے لیے native متن) پڑھتی اور نکالتی ہے:
   • اجلاس کا منظم خلاصہ۔
   • ایکشن آئٹمز — ہر ایک owner، ownerType (company/sitd/dept/external)، due date (ISO-8601؛ Hijri محفوظ)، وضاحت، ترجیح، اور منسلک ٹکٹ کے ساتھ۔
   • ریکارڈ کردہ فیصلے، فیصلہ کن فریق کے ساتھ۔
   • شرکاء، مدعو فہرست کے خاطر cross-referenced۔
   • EN/UR/SD میں مشین ترجمہ تاکہ شرکاء اپنی ترجیحی زبان میں MoM پڑھ سکیں (mom.body_en، mom.body_ur، mom.body_sd)۔ نکالنے کے نتائج extracted_action_items میں لکھے جاتے ہیں اور خلاصہ mom.summary_ai میں۔
6. افسر جائزہ و تصدیق۔ اپلوڈ کرنے والا افسر نکالے گئے ایکشن آئٹمز کا side-by-side ویو (اصل دستاویز ↔ نکالا ہوا table) میں جائزہ لیتا ہے، کسی غلط نکالنے (غلط owner، غلط date، false positive) کو درست کرتا ہے، اور تصدیق کرتا ہے۔ یہ ایک لازمی ہیومن-ان-دا-لوپ چیک پوائنٹ ہے (اصل P2)۔ تصدیق شدہ ایکشن آئٹمز والد ٹکٹ پر ذیلی ٹاسک بن جاتے ہیں (ticket_subtasks)، ہر ایک اپنا owner، due date، اور SLA slice (§9.6) کے ساتھ؛ extracted_action_items.status converted پر flip ہوتی ہے اور قطار ذیلی ٹاسک سے back-link ہوتی ہے۔

8.2 متبادل موڈز (فیچر-فلیگڈ)

یہ موڈز default پر off ہیں اور فیچر فلیگز کے ذریعے فی محکمہ فعال ہوتے ہیں (دیکھیں §15):

تمام تینوں موڈز میں ہیومن-ان-دا-لوپ تصدیق کا قدم لازمی ہے؛ افسر کی sign-off کے بغیر کوئی ایکشن آئٹم ذیلی ٹاسک نہیں بنتی، اور منظوری کے دروازے (§9.3) کے صاف ہونے کے بغیر کوئی MoM شائع نہیں ہوتی۔

8.3 MoM لائف سائیکل خاکہ (اپلوڈ-فرسٹ)

تحریری وضاحت۔ کسی بھی اجلاس کے بعد، MoM تین موڈز میں سے ایک کے ذریعے تیار ہوتی ہے۔ default اپلوڈ-فرسٹ موڈ میں، ذمہ دار افسر محکمے کے اپنے فارمیٹ (PDF، Word، یا sign شدہ کاغذی دستاویز کی تصاویر) میں MoM اپلوڈ کرتا ہے۔ manual ٹیمپلیٹ اندراج موڈ (فیچر-فلیگڈ) میں، افسر ایک منظم portal-side ٹیمپلیٹ بھرتا ہے۔ اے آئی ٹرانسکرپشن موڈ (فیچر-فلیگڈ) میں، اجلاس ریکارڈنگ configured ٹرانسکرپشن انجن کے ذریعے transcript ہوتی ہے اور LLM ٹرانسکرپٹ سے MoM کا مسودہ تیار کرتا ہے۔ اپلوڈز کے لیے، ClamAV ہر فائل اسکین کرتا ہے؛ متاثر فائلز quarantine اور مسترد ہوتی ہیں (ایک آڈٹ واقعے کے ساتھ)، جبکہ صاف فائلز encrypted اور MinIO میں محفوظ ہوتی ہیں۔ Scanned دستاویزات pluggable کثیر لسانی OCR انجن (English، Nastaliq سمیت Urdu، اور Naskh سمیت Sindhi) سے گزر کر confidence scores کے ساتھ متن تہہ پیدا کرتی ہیں؛ born-digital فائلز OCR کو skip کرتی ہیں۔ اے آئی سروس (صلاحیت mom_extract) پھر ایک خلاصہ، مالکان اور due dates کے ساتھ منظم ایکشن آئٹمز، ریکارڈ کردہ فیصلے، اور شرکاء فہرست نکالتی ہے، اور تینوں زبانوں میں مشین ترجمے تیار کرتی ہے، extracted_action_items میں منظم قطاریں لکھتی ہے۔ اپلوڈ کرنے والا افسر نکالنے کا اصل کے ساتھ side-by-side جائزہ لیتا اور تصدیق کرتا ہے — ایک لازمی چیک پوائنٹ؛ تصدیق شدہ ایکشن آئٹمز والد ٹکٹ پر ذیلی ٹاسک بن جاتے ہیں اور extracted_action_items.status converted پر flip ہوتی ہے۔ معمول کے ٹکٹس کے لیے افسر براہِ راست شائع کرتا ہے؛ حساس یا VIP ٹکٹس کے لیے MoM کو پہلے صدرِ نشین/DG منظوری سے گزرنا چاہیے، اور مسترد یا "changes requested" اسے جائزے کے قدم پر واپس کرتی ہے۔ اشاعت پر MoM versioned اور مستقل منسلک ہوتی ہے (غیر تبدیل شدہ، پچھلی versions محفوظ)، تمام شرکاء کو ان کی ترجیحات کے مطابق ای میل، in-app، اور SMS/WhatsApp پر خودکار شیئر ہوتی ہے، اقراروں کا ٹریک اور grace کے بعد یاد دہانیوں کے ساتھ۔ اگر محکمے کے پاس e-Office انٹیگریشن فعال ہو، تو MoM سرکاری file movement کے طور پر NITB e-Office پر cross-post ہوتی ہے۔

9. MoM حالات، منظوری، اشاعت و اشتراک

9.1 MoM حالات

mom.status enum ہر MoM کی canonical persisted حالت رکھتا ہے۔ اس کے گرد لائف سائیکل (upload → scan → store → OCR → extract → review → confirm → approve → publish → distribute → acknowledge) لائف سائیکل مراحل کا ایک تسلسل ہے جسے status خانہ خلاصہ کرتا ہے۔

لائف سائیکل مراحل (علیحدہ enum values کے طور پر persisted نہیں، مگر audit_events اور mom_history میں ٹریک):

uploaded → av_scanned → stored → ocr_pending → ocr_done → extract_pending → extracted → review_pending → confirmed → approval_pending (sensitive) → approved → published → distributed → acknowledged (per recipient)۔

9.2 MoM اسٹیٹ مشین

تحریری وضاحت۔ ایک MoM draft میں پیدا ہوتی ہے — جب کوئی فائل اپلوڈ، manual ٹیمپلیٹ شروع، یا ٹرانسکرپٹ آئے۔ یہ AV اسکین، storage، OCR، اے آئی نکالنے، اور افسر-جائزے کے مراحل میں draft میں رہتی ہے؛ اس وقفے میں کسی بھی قسم کی ترامیم اسے draft میں رکھتی ہیں۔ جب افسر نکالے گئے ایکشن آئٹمز تصدیق کر چکا (اور حساس/VIP ٹکٹس کے لیے صدرِ نشین/DG منظور کر چکا) تو MoM approved میں منتقل ہوتی ہے۔ اشاعت ایکشن پھر اسے published میں منتقل کرتا ہے، جو ٹرمینل اور غیر تبدیل شدہ ہے: MoM ٹکٹ سے مستقل منسلک، versioned، خودکار شیئر، اور اس کی اقرار کی کھڑکی کھلتی ہے۔ ایک published MoM کبھی draft پر واپس نہیں آ سکتی؛ واحد exit revised راستہ ہے، جو اس وقت لیا جاتا ہے جب کوئی نئی version اس پر شائع ہو — نئی version اپنی قطار پر وہی draft → approved → published بہاؤ گزرتی ہے، اور پچھلی version superseded کے طور پر flag ہوتی ہے مگر ورڈ-بر-ورڈ دیگر طور پر محفوظ رہتی ہے۔

9.3 منظوری کا دروازہ

کیا MoM اشاعت سے پہلے منظوری چاہیے، یہ ٹکٹ کی sensitivity درجہ بندی پر منحصر ہے۔ قاعدہ وہی ہے جو حساس/VIP ٹکٹس کے لیے ثبوتِ حل کے دروازے کو گورن کرتا ہے (/specs/ur/06-ticket-workflow/ §7.3)۔

ہر منظوری فیصلہ (approve / reject / changes-requested) ایک mom_approvals قطار approver_user_id، decision، note، اور decided_at کے ساتھ، اور ایک audit_events قطار لکھتا ہے۔ منظوری روٹنگ mom_approval_config میں فی (department, ticket_classification) کنفیگر ہوتی ہے۔

9.4 اشاعت و خودکار اشتراک

اشاعت پر سسٹم:

1. MoM کو versioned، غیر تبدیل شدہ منسلک کے طور پر persist کرتا ہے۔ ہر revision ایک نئی mom_documents version قطار بناتی ہے؛ پچھلی versions محفوظ اور آڈٹ-لاگڈ رہتی ہیں، کبھی overwrite نہیں ہوتیں۔ MoM والد ٹکٹ سے مستقل منسلک ہوتی ہے اور ٹکٹ ٹائم لائن میں نظر آتی ہے۔
2. تمام شرکاء کو خودکار شیئر — کمپنی نمائندے، S&ITD فیسلیٹیٹر، محکمہ شرکاء، اور نگرانی ناظرین (اجلاس قسم کے لیے مناسب سامعین کے لیے؛ اندرونی MoM کمپنی کے ساتھ شیئر نہیں ہوتی)۔ ہر اشتراک ایک mom_distributions قطار لکھتا ہے۔ چینلز:
   • ای میل MoM منسلک کے ساتھ (یا اگر فائل بڑی ہو تو secure، وقت محدود download link)۔
   • in-app نوٹیفکیشن ٹکٹ اور MoM کے ڈیپ-لنک کے ساتھ۔
   • SMS مختصر خلاصہ + link۔
   • WhatsApp مختصر خلاصہ + link۔
   • ہر چینل کا مواد وصول کنندہ کی ترجیحی لوکیل (EN/UR/SD) میں ہے۔
3. NITB e-Office پر cross-post (ماڈیول H) اگر محکمے کے پاس e-Office انٹیگریشن فعال ہو، متعلقہ سرکاری file movement بناتے ہوئے۔
4. ٹکٹ-منسلک artefacts اپ ڈیٹ — تصدیق شدہ ایکشن آئٹمز ذیلی ٹاسک کے طور پر بنائے گئے اب ٹکٹ پر نظر آتے ہیں؛ ٹکٹ حالت اجلاس نتیجہ (§6.4) ظاہر کرتی ہے۔

9.5 اقرارِ وصولی ٹریکنگ

ہر شرکاء کا اقرار mom_acknowledgments میں شائع شدہ MoM کے خلاف ٹریک ہوتا ہے:

configurable grace (default 3 کیلنڈر دن) سے آگے غیر-اقرار وصول کنندہ کی ترجیحی چینلز کے ذریعے یاد دہانی متحرک کرتا ہے؛ دوسری یاد دہانی 7 دن پر فائر ہوتی ہے؛ configurable حتمی کھڑکی (default 14 دن) سے آگے غیر-اقرار تجزیات (§14) میں flag ہوتا ہے اور S&ITD فیسلیٹیٹر کو دکھایا جاتا ہے۔

9.6 ایکشن آئٹمز → ذیلی ٹاسک

جب افسر کوئی نکالا ہوا ایکشن آئٹم تصدیق کرتا ہے، سسٹم والد ٹکٹ پر ایک ticket_subtasks قطار بناتا ہے:

• ہر ذیلی ٹاسک والد ٹکٹ کے SLA کا ایک slice ورثا پاتا ہے (configurable؛ default = ایکشن آئٹم کی due date یا والد resolution SLA، جو بھی جلدی ہو)۔
• ہر ذیلی ٹاسک کا اپنا مالک (ایکشن آئٹم کے owner/ownerType کو org chart کے خلاف جہاں ممکن ہو solve کیا گیا)، due date، ترجیح، اور وضاحت ہے۔
• ہر ذیلی ٹاسک انفرادی طور پر حل ہونے کے قابل ہے؛ والد ٹکٹ اس وقت تک Resolved تک نہیں پہنچ سکتا جب تک تمام ذیلی ٹاسک resolve یا واضح طور پر waive نہ ہوں (proof-gate precondأition /specs/ur/06-ticket-workflow/ §7.1 میں)۔
• extracted_action_items.subtask_id سیٹ ہوتا ہے اور extracted_action_items.status converted پر flip ہوتی ہے، ایک end-to-end آڈٹ زنجیر ticket → meeting → mom → ai_run → extracted_action_item → subtask دیتی ہے۔

10. ریکارڈنگ رضامندی

کسی اجلاس کی کوئی بھی آڈیو یا ویڈیو ریکارڈنگ شروع ہونے سے پہلے — physical (مخصوص ڈیوائس) یا virtual (پرووائیڈر-سائیڈ) — پورٹل ہر شرکاء سے واضح رضامندی حاصل کرتا ہے۔ رضامندی meeting_consent میں محفوظ ہوتی ہے (فی شرکاء: scope، timestamp، IP/device، withdrawal) اور ریکارڈنگ کے آغاز پر دوبارہ دکھائی جاتی ہے۔

رضامندی کا حصول لازمی اور server-side نافذ ہے: ریکارڈنگ-بنانے endpoint تمام in-progress شرکاء کے لیے مکمل consent set کے بغیر شروع ہونے سے انکار کرتا ہے۔

11. اجلاس حالات

meetings.status enum چار canonical حالات رکھتا ہے۔ منتقلیاں server-side تصدیق شدہ ہوتی ہیں اور ہر منتقلی ایک audit_events قطار خارج کرتی ہے۔

11.1 اجلاس اسٹیٹ مشین

تحریری وضاحت۔ ایک اجلاس scheduled اس وقت پیدا ہوتا ہے جب منتظم اسے بناتا ہے اور دعوت نامے بھیجے جاتے ہیں؛ یہ scheduled میں کسی بھی تعداد میں ری شیڈول ہو سکتا ہے۔ جب منتظم اجلاس شروع کرتا ہے (اور TRI/سماعتوں کے لیے کورم مکمل ہوتا ہے)، تو یہ in_progress میں منتقل ہوتا ہے۔ ختم ہونے پر یہ completed میں منتقل ہوتا ہے، جس نقطہ پر MoM لائف سائیکل (§8) سنبھالتا ہے۔ scheduled یا in_progress سے اجلاس cancelled میں منتقل کیا جا سکتا ہے — منتظم کے ذریعے، نگرانی طبقے کے ذریعے، یا خودکار طور پر جب والد ٹکٹ ٹرمینل حالت تک پہنچے۔ completed اور cancelled دونوں اجلاس ریکارڈ کے لیے ٹرمینل ہیں (ریکارڈ آڈٹ کے لیے محفوظ)؛ صرف MoM لائف سائیکل completed سے جاری رہتا ہے۔

12. سماعت نتائج

سماعتوں (T4) کے لیے فیصلہ کن کے ریکارڈ کردہ نتیجہ کا ذخیرہ الفاظ عام TRI نتیجہ سے زیادہ بھرپور ہے، کیونکہ سماعت پابند فیصلے produce کر سکتی ہے:

غیر-سماعت اجلاس اقسام کے لیے نتیجہ ذخیرہ الفاظ عمومی TRI سیٹ ہے (حل شدہ / مزید ایکشن آئٹمز / ایسکیلیٹ / ملتوی — §6.4)۔

13. نوٹیفکیشن و یاد دہانیاں

نوٹیفکیشن ماڈیول (G) تمام اجلاس- اور MoM-متعلقہ نوٹیفکیشنز کے لیے delivery substrate ہے۔ واقعہ keys، چینلز، اور ٹیمپلیٹس notification_templates میں فی لوکیل کنفیگر ہوتے ہیں۔

تمام نوٹیفکیشنز ٹیمپلیٹڈ، کثیر لسانی (EN/UR/SD) ہیں اور ماڈیول G کے مطابق ہر وصول کنندہ کا preference center (digest mode، quiet hours) کا احترام کرتی ہیں۔

14. کثیر لسانی OCR و ترجمہ

سندھ حکومت کے استعمال میں MoMs اکثر اردو (سرکاری دفتری زبان) میں، کثرت سے سندھی (صوبائی زبان) میں، اور بعض اوقات انگریزی میں ہوتی ہیں۔ MoM pipeline end-to-end کثیر لسانی ہے:

• OCR تینوں زبانوں کی معاونت کرتا ہے، اردو Nastaliq اور سندھی Naskh scripts سمیت، pluggable OCR انجن (/specs/ur/07-ai-ocr-spec/ §3.2) کے ذریعے۔ کم-confidence spans کو اے آئی نکالنے سے پہلے human correction کے لیے OCR جائزہ قطار پر روٹ کیا جاتا ہے۔
• اے آئی نکالنا کوئی بھی source لوکیل قبول کرتا ہے اور source_locale کے ساتھ ٹیگ شدہ منظم آؤٹ پٹ (خلاصہ، ایکشن آئٹمز، فیصلے) produce کرتا ہے۔
• ترجمہ LLM-بیسڈ مترجم glossary injection (/specs/ur/07-ai-ocr-spec/ §3.4، §4.6) کے ساتھ تینوں لوکیلز (mom.body_en، mom.body_ur، mom.body_sd) میں متوازی متن produce کرتا ہے۔ سرکاری-قانونی MoM متن (سماعت احکامات، پابند فیصلے) اشاعت سے پہلے ترجمے کے human جائزے کا تقاضا کرتا ہے۔
• RTL rendering اردو اور سندھی کے لیے renderer (docs کے لیے Docusaurus لوکیل؛ portal UI کے لیے Next.js لوکیل) سنبھالتا ہے؛ محفوظ مواد میں کوئی inline direction hacks نہیں۔
• تاریخیں گریگورین اور ہجری (جہاں موجود ہو) دونوں میں محفوظ رہتی ہیں؛ LLM کو ہدایت ہے کہ وہ ہجری تاریخیں خاموشی سے convert نہ کرے (/specs/ur/07-ai-ocr-spec/ §4.11)۔
• لغت کی پابندی 100% نافذ ہے: _glossary.md سے حکومتی-اصطلاحات mappings ہر ترجمہ prompt میں inject کی جاتی ہیں اور آؤٹ پٹ ان کے خلاف validate ہوتا ہے۔

15. ڈیٹا ماڈل خلاصہ

ماڈیول-M ٹیبلز /specs/ur/05-data-model/ §4.9 میں canonically تعریف شدہ ہیں۔ یہ قسم entity سیٹ، تعلقات، اور وہ دو schema deltas مرتّب کرتی ہے جو یہ دستاویز ڈیٹا ماڈل سے تقاضا کرتی ہے۔

15.1 Entity سیٹ

15.2 Schema deltas (یہ دستاویز تقاضا کرتی ہے)

1. meetings.type enum توسیع۔ موجودہ enum ('tri','hearing','internal') کو §2 میں تمام پانچ اقسام کو cover کرنے کے لیے توسیع دینی چاہیے۔ تجویز کردہ: ('tri','hearing','internal','company_direct','site_visit')۔ مزید درجہ بندی کے لیے ایک subtype VARCHAR(48) NULL امتیاز کار شامل کریں (مثلاً hearing کے تحت "adjudication"، internal کے تحت "internal_briefing")۔ دستاویز 05 §4.9 دیکھیں۔
2. meeting_consent نیا table۔ کالم: id PK، meeting_id FK، user_id FK، scope ENUM('audio','audio_video','transcript')، granted TINYINT(1)، captured_at DATETIME(6)، withdrawn_at DATETIME(6) NULL، device_fingerprint VARCHAR(255)۔ (meeting_id, user_id, scope) پر منفرد۔ §10 کے ذریعے درکار۔

یہ deltas مستند ماڈیول-M تقاضے کے طور پر یہاں نوٹ کیے گئے ہیں؛ canonical DDL /specs/ur/05-data-model/ میں ہے اور اسے match کرنے کے لیے اپ ڈیٹ کرنا چاہیے۔

15.3 Entity تعلقات

تحریری وضاحت۔ ایک tickets قطار صفر یا زیادہ meetings متحرک کرتی ہے۔ ہر اجلاس کے کئی شرکاء ہوتے ہیں (اندرونی users users کے ذریعے منسلک، بیرونی نام سے ریکارڈ)، بالکل ایک mom (1:1) produce کرتا ہے، متعدد meeting_recordings (فی ریکارڈنگ scope ایک) رکھ سکتا ہے، اور کسی ریکارڈنگ کے لیے فی-شرکاء meeting_consent capture کرتا ہے۔ mom صفر یا زیادہ mom_approvals (صرف جب ٹکٹ حساس/VIP ہو) کے ذریعے gated، متعدد mom_distributions (فی وصول کنندہ فی چینل ایک) کے ذریعے شیئر، اور mom_acknowledgments کے ذریعے اقرار شدہ ہوتی ہے۔ MoM کے source کی اے آئی نکالنے سے متعدد extracted_action_items پیدا ہوتے ہیں، جن میں سے ہر ایک افسر کی تصدیق پر زیادہ سے زیادہ ایک ticket_subtask میں convert ہوتا ہے۔ تمام binary مواد (MoM source فائل، ریکارڈنگ blob، ریکارڈنگ ٹرانسکرپٹ) MinIO میں rest پر encrypted media_library قطارات کے طور پر محفوظ ہوتا ہے، content ٹیبلز سے فورن key کے ذریعے referenced۔

16. تجزیات

ماڈیول-M تجزیات تجزیات ماڈیول (I) اور /specs/ur/17-analytics-kpis/ میں تعریف کردہ dashboards کو فیڈ کرتے ہیں۔ اجلاس اور MoM کے لیے مخصوص metric families:

تمام metrics کو محکمہ، زمرہ، لوکیل، اور وقت کی کھڑکی کے مطابق slice کیا جاتا ہے، اور تجزیات ماڈیول کے معیاری export چینلز (PDF/Excel/CSV) کے ذریعے export اور scheduled digests میں دکھایا جاتا ہے۔

17. فعال تقاضے

18. غیر-فعال تقاضے

19. صارف کہانیاں

US-MTG-001 — رکے ہوئے ٹکٹ سے TRI اجلاس کی درخواست [لازمی]

بطور کمپنی نمائندہ (بنیادی/ایڈمن) میں چاہتا ہوں کہ اپنے رکے ہوئے ٹکٹ پر "Request TRI meeting" کلک کروں اور S&ITD کمپنی + S&ITD + محکمہ کو ایک اجلاس میں بلائے تاکہ میرا مسئلہ بغیر ہر فریق کو علیحدہ طور پر پیچھے چلے unblock ہو جائے۔

قبولیت معیارات (Gherkin)

Scenario: Company requests TRI on an escalated ticket
  Given a ticket owned by me is in status Escalated at tier 2
  And I am the Primary Authorized Rep for the filing company
  When I click "Request TRI meeting" and confirm
  Then a meetings row of type "tri" is created and linked to the ticket
  And the ticket status moves to On Hold with reason "TRI meeting requested"
  And the S&ITD facilitator is notified to convene
  And an audit event "meeting.requested" is recorded

Scenario: Sensitive ticket requires convening approval
  Given the ticket is flagged sensitive = true
  When I request a TRI meeting
  Then the request routes to the Chair/DG approval queue
  And no invitations are sent until approval is granted

US-MTG-002 — MoM اپنے محکمے کے فارمیٹ میں اپلوڈ کریں [لازمی]

بطور محکمہ افسر (نوٹ لینے والا) میں چاہتا ہوں کہ MoM کو اپنے محکمے کے ٹیمپلیٹ میں PDF/Word/scan کے طور پر اپلوڈ کروں تاکہ مجھے اپنی سرکاری روداد کو portal ٹیمپلیٹ میں دوبارہ فارمیٹ کرنے کی ضرورت نہ ہو۔

قبولیت معیارات (Gherkin)

Scenario: Successful upload of a scanned MoM
  Given a meeting of any type has status completed and no MoM yet
  When I upload a scanned PDF of the department's MoM
  Then ClamAV scans the file and, on clean, encrypts and stores it
  And a mom row is created with status draft and source_media_id set
  And OCR runs in EN/UR/Sindhi producing a text layer
  And the AI extracts summary, action items, decisions, and attendees
  And extracted_action_items rows are created for officer review

US-MTG-003 — نکالے گئے ایکشن آئٹمز کو ذیلی ٹاسک میں تصدیق کریں [لازمی]

بطور محکمہ افسر میں چاہتا ہوں کہ اے آئی-نکالے گئے ایکشن آئٹمز کا اصل MoM کے ساتھ side-by-side جائزہ لوں اور درست کو تصدیق کروں تاکہ صرف درست وعدے ٹکٹ ذیلی ٹاسک بنیں۔

قبولیت معیارات (Gherkin)

Scenario: Confirm a correctly extracted action item
  Given an extracted_action_item exists with owner "Company Primary Rep" and due date "2026-08-15"
  When I review it side-by-side, correct a typo, and click Confirm
  Then a ticket_subtask is created on the parent ticket with the corrected owner, due date, priority
  And the extracted_action_item.status flips to "converted" and subtask_id is set
  And an audit event records the confirmation

Scenario: Reject a false-positive extraction
  Given an extracted_action_item is in fact a general statement, not a commitment
  When I delete it from the review list
  Then no sub-task is created
  And the item is marked rejected with the officer as actor

US-MTG-004 — حساس MoM صدرِ نشین/DG منظوری کے ساتھ شائع کریں [لازمی]

بطور S&ITD فیسلیٹیٹر میں چاہتا ہوں کہ حساس ٹکٹ کی MoM شیئر ہونے سے پہلے صدرِ نشین/DG منظوری کا تقاضا کرے تاکہ حساس مواد کمپنی تک پہنچنے سے پہلے جوابد اتھارٹی کے جائزے سے گزرے۔

قبولیت معیارات (Gherkin)

Scenario: Sensitive MoM routed to approval queue
  Given the parent ticket is sensitive = true
  And the officer has confirmed all extracted action items
  When the MoM is submitted for publish
  Then its status stays draft and a mom_approvals row is created pending
  And the Chair/DG approval queue is notified
  And no auto-share occurs

Scenario: Approval granted then published
  Given a sensitive MoM is pending approval
  When the Chair approves it
  Then the mom.status moves to approved then published
  And auto-share fans out to all participants per §9.4
  And mom_distributions rows are written for each channel/recipient

US-MTG-005 — MoM اپنی زبان میں وصول کریں اور اقرار کریں [لازمی]

بطور کمپنی نمائندہ میں چاہتا ہوں کہ شائع شدہ MoM اپنی ترجیحی زبان میں وصول کروں اور اقرار کروں تاکہ مجھے کیا طے پایا گیا اس کا مستند ریکارڈ ہو اور سسٹم ٹریک کرے کہ میں نے وصول کر لیا۔

قبولیت معیارات (Gherkin)

Scenario: Acknowledge a published MoM
  Given a MoM for a meeting I attended has been published
  When I receive the in-app notification and click through to the MoM
  Then the MoM is rendered in my preferred locale (EN/UR/SD)
  And my open is recorded as an acknowledgment of type "opened"
  And when I click "I acknowledge" an "explicit_ack" row is written
  And no further reminders are sent to me

20. ٹیسٹ کیسز (حوالہ)

21. فیچر فلیگز

فلیگز feature_flags میں محفوظ ہیں (/specs/ur/05-data-model/ §4 دیکھیں) اور سپر ایڈمن کے ذریعے فی (department, environment) ماڈیول Q کے مطابق منتظم۔

22. کنفیگریشن میٹرکس

23. کراس-حوالہ جات

• _context.md §5 — MoM اپلوڈ-فرسٹ، TRI سہ فریقی، منظوری صرف حساس/VIP کے لیے، آٹو-شیئر پر locked فیصلے۔
• /specs/ur/05-data-model/ §4.9 — meetings، meeting_attendees، mom، mom_approvals، mom_distributions، mom_acknowledgments، meeting_recordings، extracted_action_items کے لیے canonical schema۔
• /specs/ur/06-ticket-workflow/ §9–§10 — ٹکٹ لائف سائیکل میں TRI اور MoM خلاصہ؛ §7 ثبوتِ حل دروازہ؛ §7.3 حساس/VIP closure منظوری۔
• /specs/ur/07-ai-ocr-spec/ §3.2 — OCR انجنز؛ §4.1 OCR صلاحیت؛ §4.6 ترجمہ؛ §4.11 canonical prompt ٹیمپلیٹ اور کامیابی metrics کے ساتھ mom_extract صلاحیت۔
• /specs/ur/04-roles-permissions/ — RBAC کس درخواست، منعقد، حاضر، اپلوڈ، منظور، اشاعت، اور اقرار کر سکتا ہے۔
• /specs/ur/11-security-compliance/ — rest پر encryption، retention، رضامندی ہینڈلنگ، آڈٹ logging۔
• /specs/ur/15-tech-architecture/ §9 — ClamAV اسکین pipeline؛ MinIO object storage۔
• /specs/ur/17-analytics-kpis/ — ماڈیول-M metrics استعمال کرنے والے تجزیات dashboards۔
• _glossary.md — MoM، TRI، سماعت، فیسلیٹیٹر وغیرہ کے لیے کثیر لسانی لغت۔

24. کھلے سوالات