اجلاسون، TRI ۽ اجلاس جي روداد

ڪنهن ٽِڪيٽ سان منسلڪ سڀني اجلاسن — ٽن ڌرين (TRI) جائزن، سماعت، محڪماتي ۽ سڌي اجلاسن، ۽ سائيٽ وزٽس — ۽ اپلوڊ-فرسٽ اجلاس جي روداد (MoM) لائف سائيڪل، اي آءِ نڪرڻ واري عمل، منظوريءَ جي دروازي، اشاعت ۽ خودڪار شيئر، ۽ سنڌ آءِ ٽي پورٽل — سهولت ڊيسڪ (SITP) تي تجزيات لاءِ مستند تفصيل.

1. دائرو ڪار ۽ تعريفون

هي دستاويز ماڊيول M لاءِ اڪيلو مستند ماخذ آهي. هن ۾ هر اهڙي قسم جي اجلاس جي تعريف آهي جيڪا ڪنهن ٽِڪيٽ سان منسلڪ ٿي سگهي، اجلاس ڪيئن شيڊول ٿين ٿا، انهن جون رودادون ڪيئن تيار ۽ شيئر ٿين ٿيون، ۽ روداد اندر موجود ايڪشن آئٽمز ڪيئن ذيلي ٽاسڪ جي حيثيت سان ٽِڪيٽ ۾ واپس اچن ٿا. هي /specs/sd/05-data-model/ §4.9 ۾ تعريف ٿيل meetings, meeting_attendees, mom, mom_approvals, mom_distributions, mom_acknowledgments, ۽ meeting_recordings ٽيبلز لاءِ معياري حوالو آهي.

ٽِڪيٽ لائف سائيڪل، SLA، اِسڪيليشن ڏاڪي، ثبوتِ حل جو دروازو، ٻيهر کولڻ/اپيل جون مدتون، ۽ /specs/sd/06-ticket-workflow/ §9–§10 ۾ موجود TRI/MoM خلاصو اُتي گورن ٿيا؛ هي دستاويز انهن کي مڪمل ماڊيول-M تفصيل ۾ پکيڙي ٿو. جتي ٻنهي دستاويزن ۾ فرق معلوم ٿئي، ماڊيول-M رويي لاءِ هيءَ دستاويز ئي مستند آهي ۽ ٽِڪيٽ-ورڪ فلو دستاويز ان جي تابع آهي.

لغت (مختصر صورت؛ ڏسو _glossary.md):

هتي بيان ڪيل سڀئي صلاحيتون فيچر فليگ ماڊيول (Q) ذريعي انفرادي طور تي ٽوگل ٿيڻ جون قابل آهن ۽ §15 ۾ بيان ڪيل في-محڪمي / في-قسم کنفيگريشن ذريعي انفرادي طور تي کنفيگر ٿيڻ جون قابل آهن.

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

ڪو به اجلاس هميشه بالڪل هڪ ئي ٽِڪيٽ سان منسلڪ هوندو آهي (meetings.ticket_id فورن ڪي). هڪ ٽِڪيٽ جي حياتي ۾ ڪيترائي اجلاس ٿي سگهن ٿا. سسٽم پنجن قسمن جا اجلاس تسليم ڪري ٿو، جيڪي مقصد ۽ حاضر ٿيندڙ ڌرين جي بنياد تي درجه بنڊ آهن. ڊيٽا ماڊل جو meetings.type enum (ڏسو /specs/sd/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/sd/06-ticket-workflow/ §5.4) ته جيئن شيڊولنگ ٻنهي جو احترام ڪري.

3.2 دستيابي ۽ متصادم چيڪس

شيڊولنگ تي، پورٽل سڀني مدعو فردن جي ڪيلينڊرز ۽ ميٽنگ روم / ورچوئل-پرووائڊر وسيلن تي هڪ متصادم چيڪ هلائي ٿو:

• هڪ هارڊ متصادم (ڪنهن مدعو جو اڳ ۾ ئي scheduled يا in_progress اجلاس تجويز ڪيل سلاٽ سان متصادم آهي) ان مدعو لاءِ ان سلاٽ کي بلاڪ ڪري ڏئي ٿو ۽ ±N ڪاروباري ڪلاڪن اندر (default N = 2) متبادل خالي سلاٽس ڏيکاري ٿو، هر مدعو جي محڪمي جي ڪاروباري ڪلاڪن جو احترام ڪندي.
• هڪ سافٽ متصادم (ڪنهن مدعو کي ٻي اجلاس تي "عارضي" نشاني لڳل آهي، يا هو ڪاروباري ڪلاڪن کان ٻاهر آهي) تنبيه ڪندو آهي مگر بلاڪ ناهي ڪندو.
• موڪل چيڪ ڪنهن به ان سلاٽ کي مسترد ڪندو آهي جيڪو سنڌ جي سرڪاري موڪل تي اچي ٿو (holiday_calendar ڏسو)؛ شيڊيولر ايندڙ ڪاروباري ڏينهن تجويز ڪندو آهي. هجري تاريخ جون موڪلون (عيد، عاشوره وغيره) هر سال /specs/sd/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/sd/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/sd/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/sd/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/sd/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/sd/07-ai-ocr-spec/ §3.2 ۽ §4.1 مطابق گذرنديون آهن. OCR گهڻ لساني (EN + UR + سنڌي، Nastaliq ۽ Naskh scripts سميت) آهي ۽ confidence scores سان searchable متن جي تهاه پيدا ڪندو آهي؛ گهٽ-confidence spans جائزي لاءِ flag ٿينديون آهن.
5. اي آءِ ڪڍڻ. اي آءِ سروس (ماڊيول E، صلاحيت mom_extract، /specs/sd/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 سميت سنڌي) مان گذري 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/sd/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 precondition /specs/sd/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 نتيجي کان وڌيڪَ ڀرپور آهي، ڇاڪاڻ ته سماعت پابند فيصلا پيدا ڪري سگهي ٿي:

غير-سماعت اجلاس قسمن لاءِ نتيجو لفظ ذخيرو عمومي 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/sd/07-ai-ocr-spec/ §3.2) ذريعي. گهٽ-confidence spans کي اي آءِ ڪڍڻ کان اڳ human correction لاءِ OCR جائزو قطار تي روٽ ڪيو ويندو آهي.
• اي آءِ ڪڍڻ ڪابه به source لوڪيل قبول ڪندو آهي ۽ source_locale سان ٽيگ ٿيل منظم آئوٽ پٽ (خلاصو، ايڪشن آئٽمز، فيصلا) پيدا ڪندو آهي.
• ترجمو LLM-بيسڊ مترجم glossary injection (/specs/sd/07-ai-ocr-spec/ §3.4، §4.6) سان گڏ ٽِنهي لوڪيلز (mom.body_en، mom.body_ur، mom.body_sd) ۾ متوازي متن پيدا ڪندو آهي. سرڪاري-قانوني MoM متن (سماعت احڪام، پابند فيصلا) اشاعت کان اڳ ترجمي جي human جائزي جو تقاضو ڪندو آهي.
• RTL rendering اردو ۽ سنڌي لاءِ renderer (docs لاءِ Docusaurus لوڪيل؛ portal UI لاءِ Next.js لوڪيل) سنڀاليندو آهي؛ محفوظ مواد ۾ ڪابه inline direction hacks ناهي.
• تاريخون گريگورين ۽ هجري (جتي موجود هجن) ٻنهي ۾ محفوظ رهنديون آهن؛ LLM کي هدايت آهي ته هو هجري تاريخون خاموشي سان convert نه ڪري (/specs/sd/07-ai-ocr-spec/ §4.11).
• لغت جي پابندي 100% نافذ آهي: _glossary.md مان حڪومتي-اصطلاحات mappings هر ترجمو prompt ۾ inject ڪيا ويندا آهن ۽ آئوٽ پٽ انهن جي خلاف validate ٿيندو آهي.

15. ڊيٽا ماڊل خلاصو

ماڊيول-M ٽيبلز /specs/sd/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/sd/05-data-model/ ۾ آهي ۽ ان کي match ڪرڻ لاءِ اپڊيٽ ٿيڻ گهرجي.

15.3 Entity تعلقات

تحريري وضاحت. هڪ tickets قطار صفر يا وڌيڪَ meetings متحرڪ ڪندي آهي. هر اجلاس جا ڪيترائي شرڪا هوندا آهن (اندروني users users ذريعي منسلڪ، بيروني نالي سان رڪارڊ)، بالڪل هڪ mom (1:1) پيدا ڪندو آهي، ڪيتريون 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/sd/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/sd/05-data-model/ §4 ڏسو) ۽ سپر ايڊمن پاران في (department, environment) ماڊيول Q مطابق منتظم.

22. کنفيگريشن ميٽرڪس

23. ڪراس-حوالا

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

24. کليل سوال