ملٽي چينل انٽيڪ

سندھ آءِ ٽي پورٽل — سهولت ڊيسڪ (SITP) لاءِ مستند هدايت نامو ته پورٽل ڪنهن به چينل مان ايندڙ هر اندروني رابطي کي ڪيئن هڪ ٽريڪ ٿيل، روٽ ٿيل، غير ٻيهر ورجايل، گهڻ لساني ٽڪيٽ ۾ بدلائي ٿو — ڪمپنين ۽ شهزورن سان انهيءَ جاءِ تي ملي ٿو جتي اهي اڳ ۾ ئي موجود آهن.

خانو	قدر
دستاويز آءِ ڊي	19
حيثيت	ڊرافٽ
مالڪ	S&ITD / MAAHIR
ٻوليون	EN (استاد) · UR · SD
ماڊيول تي لاڳو	K — ملٽي چينل انٽيڪ (MCI)
لاڳاپيل دستاويزون	`/specs/sd/02-functional-reqs/` (MCI FRs)، `/specs/sd/08-integrations-spec/` (Mailjet/SMS/WhatsApp معاهدا)، `/specs/sd/06-ticket-workflow/`، `/specs/sd/15-tech-architecture/`، `/specs/sd/05-data-model/`، `/specs/sd/11-security-compliance/`، `/specs/sd/24-trust-safety/`
حاصل ڪري ٿو	`FR-MCI-001` … `FR-MCI-007`

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

هي دستاويز پورٽل جي هر چينل تي انٽيڪ جي واحد مستند ماخذ آهي. اها تعين ڪري ٿي ته ڇا شيءِ چينل شمار ٿئي ٿي، هڪ پيغام ڪيئن ٽڪيٽ بڻجي ٿو (يا ڪنهن ٽڪيٽ سان منسلڪ ٿئي ٿو)، هڪ ئي شڪايت جيڪا ٻن مختلف چينلز ذريعي ٻه ڀيرا داخل ڪئي وئي هجي کي ڪيئن سڃاتو ۽ ضم ڪيو وڃي ٿو، ۽ نظام ڪيئن دستياب رهي ٿو ان صورت ۾ به جڏهن ڪو انفرادي فراهم ڪندڙ بند هجي.

پورٽل جو مقامي ويب انٽيڪ فارم ۽ پارٽنر پبلڪ REST API (POST /api/v1/tickets، ڏسو /specs/sd/12-api-contract/) بنيادي انٽيڪ رستا آهن ۽ مڪمل طور /specs/sd/06-ticket-workflow/ ۾ متعين آهن. هي دستاويز ان بنياد تي رکيل پنجن ملٽي چينل انٽيڪ رستن جو احاطو ڪري ٿو، ته جيئن شهري کي پنهنجي ڳالهه کڻائڻ لاءِ ڪڏهن به ويب فارم ۾ لاگ اِن نه ڪرڻو پوي:

اي ميل کان ٽڪيٽ
SMS کان ٽڪيٽ
WhatsApp کان ٽڪيٽ
ٽول فري IVR / وائس
پيرين / آف لائن اندراج

هر چينل انهيءَ ئي ٽڪيٽنگ ڪور، انهيءَ ئي SLA/اسڪيليشن انجن، انهيءَ ئي AI درجه بندي، ۽ انهيءَ ئي آڊٽ لاگ تي گڏ ٿئي ٿو. چينل هڪ اصليتِ پيدائش وارو صفات آهي، ڪڏهن به متوازي ورڪ فلو ناهي.

لغت (مختصر شڪل؛ مڪمل لاءِ _glossary.md ڏسو):

اصطلاح	معنيٰ
انٽيڪ چينل	اها ٽرانسپورٽ جنهن ذريعي ڪو اندروني رابطو وصول ٿئي ٿو ۽ ٽڪيٽ بڻجي ٿو يا منسلڪ ٿئي ٿو (ويب، اي ميل، SMS، WhatsApp، IVR، پيرين، API)۔
ان باؤنڊ	اهڙو پيغام جيڪو ڪنهن ٻاهرين موڪليندڙ کان SITP ۾ اچي ٿو (اطلاع جي اُپٽ).
چينلِ اصليت	هر ٽڪيٽ تي محفوظ صفت جيڪا رڪارڊ ڪري ٿي ته ڪهڙي چينل ان کي پيدا ڪيو (`FR-MCI-006`).
ٿريڊ ميچنگ	ڪنهن ايندڙ جواب کي ان ٽڪيٽ سان منسلڪ ڪرڻ جنهن سان لاڳاپو آهي، ٽريڪنگ آءِ ڊي، in-reply-to/References هيڊرز، يا جواب جي سياق سباق جي بنياد تي.
ڊي ڊپ (Dedup)	اهو سڃاڻپ ته ڪو نئون ان باؤنڊ پيغام ڪنهن موجوده کُليل ٽڪيٽ جيئن ئي شڪايت ڪندڙ + مسئلو بيان ڪري ٿو، چينلز کان قطعِ نظر.
عارضي سڃاڻپ	اهڙو موڪليندڙ جنهن جو فون/اي ميل/CNIC اڃا ڪنهن رجسٽرڊ تنظيم/نمائندي سان ميپ ناهي ٿيندو؛ ٽڪيٽ پوءِ به بڻجي ۽ منسوب ٿئي ٿو.
سهولت ڪائونٽر	هڪ عملو وارو ڊيسڪ (S&ITD يا پارٽنر محڪمو) جتي پيرين ايندڙ شكايتون ڪنهن زائر جي طرفان داخل ڪيون وڃن ٿيون.
موڪليندڙ	پيغام جي ان باؤنڊ طرف تي موجود شخص/تنظيم، چينل کان قطعِ نظر.

هيٺ ڏنل سڀ صلاحيتون انفرادي طور تي فيچر فليگ ماڊيول (Q) ذريعي ٽوگل ٿي سگهن ٿيون ۽ /specs/sd/06-ticket-workflow/ §15 مطابق هر محڪمي لاءِ ڪنفيگر ٿي سگهن ٿيون.

2. اصول — ڪمپنين سان انهن وٽ مليو جتي اهي آهن

پورٽل جو مفاد سنڌ حڪومت سان IT انڊسٽري جا مسئلا حل ڪرڻ لاءِ هڪ سنگل ونڊو رکڻ آهي. اها سنگل ونڊو جيڪا صرف لاگ اِن ٿيل ويب فارم ذريعي جمع ٿيل قبول ڪري، عملي طور تي سنگل ونڊو ناهي — اها هڪ رڪاوٽ آهي. پاڪستاني IT ڪمپنيون، فري لينسرز، ۽ انهن سان تعامل رکندڙ شهري ڪنهن پورٽل ۾ ناهن رهندا؛ اهي WhatsApp، SMS، اي ميل، ۽ فون ۾ رهن ٿا. ڪو به فيلڊ آفيسر جو ڪنهن سافٽ ويئر پارڪ جو دورو ڪري رهيو هجي، هميشه ڪنيڪٽيوٽي ناهي رکندو.

انهي ڪري ملٽي چينل انٽيڪ ماڊيول چار لازميتن تي عمل ڪري ٿو:

آءِ ڊي	لازميت	معنيٰ
MC-1	هر چينل ساڳئي ٽڪيٽ پيدا ڪري ٿو. ڪا "اي ميل ٽڪيٽ" ناهي، ڪا "WhatsApp ٽڪيٽ" ناهي. WhatsApp مان بڻيل ٽڪيٽ ساڳئو رڪارڊ آهي، ساڳي ٽريڪنگ آءِ ڊي فارميٽ، SLA، اسڪيليشن ليڊر، حل جي ثبوت جو گیٽ، آڊٽ ٽريل، ۽ تجزياتي ابعاد سان، جهڙوڪ ويب فارم مان بڻيل.
MC-2	سڻجڻ لاءِ لاگ اِن ضروري ناهي. غير رجسٽرڊ يا غير مصدق موڪليندڙ هميشه ان باؤنڊ چينل ذريعي داخل ڪري سگهي ٿو؛ نظام هڪ عارضي سڃاڻپ ٺاهي ٿو ۽ پوءِ رجسٽريشن جي پيشڪش ڪري ٿو. تصديق اعتماد وڌائي ٿي، رسائي ناهي.
MC-3	آمد جي چينل ۾ جواب ڏيو. وصولي تصديقون، حيثيت جون اپڊيٽس، ۽ آفيسرن جا پيغام موڪليندڙ تي ان چينل پهچن ٿا جنهن جو هن پورٽل سان رابطي لاءِ استعمال ڪيو، ۽ جيڪڏهن اها چينل خراب ٿي وڃي ته ڪراس چينل فال بیک موجود آهي.
MC-4	چينل ڊيٽا آهي، مقدر ناهي. چينلِ اصليت رڪارڊ، تجزيو، ۽ آڊٽ ٿئي ٿي — پر ڪنهن به ٽڪيٽ جا حق، SLA، يا روٽنگ منطق بدل ناهي ڪندي. ڪو به ٽڪيٽ ان لاءِ "گهٽ اهم" ناهي ته هو SMS مان آيو.

انهن لازميتن جو حوالو هن دستاويز ۾ ۽ /specs/sd/02-functional-reqs/ §MCI جي قبوليت جي معيارن ۾ آءِ ڊي سان ڏنو ويو آهي.

3. انٽيڪ پائپ لائن

3.1 جائزو

چينل کان قطعِ نظر، هر ان باؤنڊ پيغام ٽڪيٽ يا تبصرو بڻجڻ کان اڳ انهيءَ ئي ست مرحلن واري پائپ لائن مان لنگهي ٿو. هي پائپ لائن هڪ BullMQ ورڪر چين جي صورت ۾ نافذ آهي؛ هر مرحلو idempotent آهي، آزادانه طور retryable آهي، ۽ هڪ audit_events قطار emit ڪري ٿو. مرحلا هي آهن:

انجسٽ (Ingest) — چينل ايڊاپٽر کان خام پے لوڊ وصول ڪريو (Mailjet ان باؤنڊ parse، SMS MO، WhatsApp Cloud API ويب هوڪ، IVر رڪارڊنگ ڪال بیک، PWA سنڪ بيچ)۔
نارملائيز (Normalize) — هڪ معياري InboundMessage ڪڍو (موڪليندڙ جا سڃاڻپگر، خام متن، منسلڪات، لوڪيل اشارا، چينل مخصوص ميٽا ڊيٽا) ۽ جيڪو به ساختي تسديد ۾ ناڪام ٿيندو تنهن کي ڇڏيو يا قرنطينه ڪيو. |
PII سڃاڻپ ۽ حذف — متن ۽ OCR مان نڪتل منسلڪ متن تي PII سڃاڻپ (FR-AI-009) هلائيو؛ ڪنهن به ڪلائوڊ AI ڪال کان اڳ CNIC/فون/اي ميل کي tokenize ڪريو؛ حذف جو نقشو آن پريميس رکو. |
ڊي ڊپ چيڪ — موڪليندڙ جي کُليل ٽڪيٽن ۽ حاليه حل ٿيل ٽڪيٽن جي خلاف مماثلت سڃاڻپ (FR-AI-007، FR-MCI-005) هلائيو؛ ميچ ايندڙ مرحلي لاءِ سامهون آڻيو. |
AI درجه بندي — درجه بندي ڪريو ۽ روٽنگ تجويز ڪريو (FR-AI-002، FR-AI-003)؛ فوريت/جذباتي حالت سڃاڻيو (FR-AI-004)؛ ٻولي سڃاڻيو (§9). |
پيدا ڪريو يا منسلڪ ڪريو — يا ته نئون ٽڪيٽ ٺاهيو (FR-TKT-001 ٽريڪنگ آءِ ڊي تفويض ٿيل) يا ميچ ٿيل موجوده ٽڪيٽ تي تبصري طور منسلڪ ڪريو (ٿريڊ ميچنگ، §7). چينلِ اصليت سٽيمپ ٿئي ٿي (FR-MCI-006). |
موڪليندڙ کي تصديق — ٽريڪنگ آءِ ڊي سٽ سٽ گڏ وصولي جي تصديق انهيءَ چينل تي موڪليو جنهن مان آمد ٿي، ۽ جيڪڏهن اها چينل بند هجي ته ڪراس چينل فال بیک (§12). |

3.2 پائپ لائن خاڪو

خاڪو هڪ ئي ان باؤنڊ پيغام کي ڏيکاري ٿو جيڪو پنجن مان ڪنهن به چينل ذريعي داخل ٿئي ٿو ۽ پائپ لائن مان لنگهي ٿو. سڃاڻپ منسلڪ ڪرڻ ۽ روٽنگ جا سائڊ ايفيڪٽس ڏيکاريل مقامن تي پائپ لائن سان تعامل ڪن ٿا. فراهم ڪندڙ جي بندش (ڳاڙهي ڊاٽڊ لائين) صرف تصديقن لاءِ فال بیک چين (§12) کي متحرڪ ڪري ٿي؛ ٽڪيٽ جي تخليق پاڻ ڪڏهن به اصلي فراهم ڪندڙ تي منحصر ناهي.

flowchart TB subgraph Channels["Inbound channels (5)"] EMAIL["Email (Mailjet inbound parse)"] SMS["SMS (MO short-code keyword)"] WA["WhatsApp (Cloud API webhook)"] IVR["IVR / Voice (toll-free, STT)"] WALK["Walk-in / Offline (PWA sync batch)"] end subgraph Pipeline["Channel-agnostic intake pipeline (BullMQ)"] S1["1. Ingest (signature verify · replay protect)"] S2["2. Normalize → InboundMessage"] S3["3. PII detect & redact"] S4["4. Dedup check vs open + recent tickets"] S5["5. AI categorize (category · routing · urgency · language)"] S6{"6. Create or append?"} CREATE["Create new ticket + tracking ID + channel_of_origin"] APPEND["Append as comment to matched ticket"] end subgraph Side["Side-effects"] IDLINK["Identity linking (match phone/email/CNIC → org/rep, else Provisional)"] ROUTE["Channel-agnostic routing → dept/section + SLA tier"] RL["Rate-limit & anti-abuse (gate at ingest)"] end OUT["7. Confirm to sender (originating channel, fallback chain)"] EMAIL --> S1 SMS --> S1 WA --> S1 IVR --> S1 WALK --> S1 RL -. gate .-> S1 S1 --> S2 --> S3 --> S4 --> S5 --> S6 IDLINK -. reads/writes identity .-> S2 S6 -->|no match| CREATE S6 -->|match open ticket| APPEND CREATE --> ROUTE APPEND -. reuses existing routing .-> ROUTE CREATE --> OUT APPEND --> OUT OUT -. provider down? .-> FALL["Fallback chain (next-best channel)"]

3.3 تحريري وضاحت

پيغام پنجن مان ڪنهن به چينل تي اچي ٿو ۽ /specs/sd/08-integrations-spec/ §9.2 ۾ بيان ڪيل ان باؤنڊ ويب هوڪ ريسيور تي پهچايو ويندو آهي — هڪ واحد اڳيان دروازو جيڪو فراهم ڪندڙ جي دستخط جي تصديق ڪري ٿو، ري پلے مسترد ڪري ٿو، ۽ انٽيڪ قطار تي هڪ نارملائزڊ لفافو اماڻي ٿو. ريٽ-لِمٽ / اينٽي اِيوز گیٽ (§10) ريسيور تي لڳايو ويندو آهي، ڪنهن به مهانگي ڪم کان اڳ؛ هڪ موڪليندڙ جون ٻوڏون پائپ لائن تائين پهچڻ کان اڳ ڇڏيون يا ٿروٽل ڪيون وڃن ٿيون.

انجسٽ ورڪر لفافو پڙهي ٿو، ان کي (حساسي خانا حذف ٿيل) int_call ۾ direction inbound سان رڪارڊ ڪري ٿو، ۽ خام پے لوڈ نارملائيز مرحلي کي ڏئي ٿو، جيڪو هڪ معياري InboundMessage تيار ڪري ٿو جنهن ۾ شامل آهن: موڪليندڙ جا سڃاڻپگر (اي ميل، MSISDN، WA-verified نالو، CNIC جيڪڏهن ظاهر ڪيو، rep آءِ ڊي جيڪڏهن ميچ ٿيو)، خام موضوع/باڊي، منسلڪات (staging بکٽ ۾ presigned refs)، لوڪيل اشارا (اي ميل لاءِ Accept-Language، WA لاءِ ڊوائيس لوڪيل، SMS لاءِ سڃاتل اسڪرپٽ، IVر ڪالر طرفان بيان ڪيل ٻولي)، ۽ چينل مخصوص ميٽا ڊيٽا (پيغام آءِ ڊي، جواب جو سياق، in-reply-to/References هيڊرز، IVر ڪال آءِ ڊي، پيرين آفيسر آءِ ڊي).

PII سڃاڻپ ان کان پوءِ هلندي آهي (FR-AI-009): CNIC، فون، اي ميل، ۽ ڪنفيگر ٿيل ڪي به نمونا ڪنهن به ڪلائوڊ AI ڪال کان اڳ tokenize ٿين ٿا، ۽ حذف جو نقشو آن پريميس رکيل هوندو آهي ته جيئن اسٽوريج ۾ اصلي بحال ٿي سگهي ۽ پيشڪش تي ٻيهر ماسڪ ٿئي. منسلڪات هن مرحلي تي ClamAV ذريعي AV-scanned ٿين ٿا (FR-FILE-003) ۽ سڃاڻپ تي قرنطينه ڪيا ويندا آهن.

ڊي ڊپ (FR-MCI-005) نارملائيز ٿيل پيغام جو موازنو موڪليندڙ جي کُليل ٽڪيٽن ۽ حاليه حل ٿيل ٽڪيٽن سان مماثلت سروس (FR-AI-007) ذريعي ڪري ٿو. ميچ مماثلت اسڪورن سان موٽن ٿا، خاموشي سان ضم ناهي ٿيندا — مرحلو 6 جو پيدا ڪريو يا منسلڪ ڪريو فيصلو انهن کي استعمال ڪري ٿو.

AI درجه بندي (FR-AI-002، FR-AI-003، FR-AI-004) هڪ خلاصو، قسم، محڪمو/سيڪشن/فوريت جي تجويز اعتماد سان، ۽ جذباتي ليبل پيدا ڪري ٿو. ٻولي سڃاڻپ (§9) پيغام جي لوڪيل کي ٽيگ ڪري ٿي. جيڪڏهن AI دستياب ناهي يا اعتماد جي حد کان هيٺ آهي، ته ٽڪيٽ بنا ڪنهن روڪٽوڪ جي مينوئل ٽرائج قطار ۾ داخل ٿئي ٿو.

پيدا ڪريو يا منسلڪ ڪريو فيصلو پائپ لائن ۾ واحد شاخ آهي:

ڪابه پختہ ڊي ڊپ ميچ ناهي (يا صرف حل ٿيل ميچ) → معياري ٽريڪنگ آءِ ڊي (FR-TKT-001) سان نئون ٽڪيٽ ٺاهيو، channel_of_origin سٽيمپ ڪريو (FR-MCI-006)، ٽرائج آفيسر لاءِ AI تجويزون منسلڪ ڪريو، ۽ هدف محڪمي/سيڪشن ۽ SLA درجي تائين چينل کان آزاد روٽنگ (§8) متحرڪ ڪريو. |
کُليل ٽڪيٽ جي خلاف پختہ ڊي ڊپ ميچ → ان باؤنڊ کي ميچ ٿيل ٽڪيٽ تي هڪ پبلڪ تبصري طور منسلڪ ڪريو، ان ٽڪيٽ جي موجوده روٽنگ کي ٻيهر استعمال ڪندي؛ ڊي ڊپ جو انتخاب (اڳتي وڌو / منسلڪ ڪريو / ضم ڪريو) ٽرائج آفيسر کي ڏيکاريو وڃي ٿو ۽ FR-MCI-005 مطابق آڊٽ لاگ ٿئي ٿو. |
ٿريڊ-ميچ ٿيل جواب (اهڙو ان باؤنڊ جيڪو واضح طور ڪنهن ٽريڪنگ آءِ ڊي جو حوالو ڏئي ٿو، مثلاً ڪنهن اطلاع جو جواب) → هميشه منسلڪ ڪندو آهي، ڊي ڊپ اسڪور کان قطعِ نظر (§7). |

آخر ۾، تصدیق موڪليندڙ کي اصلي چينل تي موڪلي ويندي آهي — نئون ٽڪيٽ پنهنجو ٽريڪنگ آءِ ڊي حاصل ڪري ٿو؛ منسلڪ جواب کي وصولي ملندي آهي ته پيغام شامل ٿي ويو. جيڪڏهن اصلي فراهم ڪندڙ دستياب ناهي، ته فال بیک چين (§12) تصدیق کي ان موڪليندڙ لاءِ ايندڙ بهترين چينل ذريعي روٽ ڪري ٿي (مثلاً WhatsApp بند هجڻ جي صورت ۾ SMS فال بیک).

4. چينل جون صلاحيتون (meترڪس)

پنج ان باؤنڊ چينلز بينڊوڊٿ، منسلڪات جي سپورٽ، ٻه طرفي صلاحيت، ۽ ريگيوليٽري انحصار ۾ فرق رکن ٿيون. هيٺ ڏنل جدول اها صلاحيت جو معاهدو آهي جيڪو هر چينل ايڊاپٽر کي پورو ڪرڻ گهرجن؛ هر چينل جون تفصيلون §5 ۾ آهن.

صلاحيت	اي ميل	SMS	WhatsApp	IVR / وائس	پيرين / آف لائن
چينل ڪوڊ (`channel_of_origin`)	`email`	`sms`	`whatsapp`	`ivr`	`walkin`
ٽرانسپورٽ	Mailjet ان باؤنڊ parse	MO تائين short-code	WA Cloud API ويب هوڪ	ٽول فري PSTN	PWA سنڪ بيچ
سمٽ	ٻه طرفو (جواب منسلڪ)	ٻه طرفو (جواب منسلڪ)	ٻه طرفو (جواب منسلڪ)	هڪ طرفو اِن + SMS/وائس آؤٽ	ٻه طرفو (آفيسر جي طرفان اندراج)
منسلڪات سپورٽ	ڪابه به قسم (AV-scanned)	ڪابه ناهي (صرف لنڪ)	تصوير / دستاويز / آڊيو / وڊيو (AV-scanned)	وائس رڪارڊنگ (آڊيو فائل)	ڪابه به قسم (سنڪ تي AV-scanned)
پيغام جي ڊيگهه	عملي طور تي لامحدود	70–160 ڪرڪٽرز/سيگمنٽ (UR/SD لاءِ UCS-2)	ڊگهو متن + ميڊيا	وقت محدود رڪارڊنگ	لامحدود (فارم تي مبني)
آمد تي تصديق	موڪليندڙ جو اي ميل + DKIM/SPF	MSISDN (SIM-bound)	WA-verified فون + opt-in	MSISDN (ڪالر آءِ ڊي)	آفيسر ڊوائيس تي مصدق
سڃاڻپ جو اشارو	اي ميل → rep/org	فون → rep/org/CNIC	فون + نالو → rep/org	فون → rep/org	آفيسر جو داخل ڪيل CNIC/org
گهڻ لساني ان باؤنڊ	ها (باڊي ۾ ڪابه به اسڪرپٽ)	ها (UCS-2 UR/SD)	ها (ڪابه به اسڪرپٽ + وائس نوٽس)	ها (IVر prompts EN/UR/SD؛ STT ڪابه به)	ها (فارم لوڪيل + املا معلوم متن)
تصديقي چينل	اي ميل (جواب)	SMS	WhatsApp ٽيمپليٽ	SMS (يا وائس ڪال بیک)	زائر جو چونڊيل چينل
MoSCoW (V1)	[M] Must	[M] Must	[M] Must	[S] Should	[M] Must
انحصار	Mailjet ان باؤنڊ روٽ، موڪليندڙ-ڊومين تصديق	short-code الاٽمينٽ، sender-ID منظوري	WABA منظوري + ٽيمپليٽ منظوريون	ٽول فري نمبر، STT فراهم ڪندڙ، IVر پليٽ فارم	PWA آف لائن اسٽوريج + سنڪ ورڪر
حيثيت	`contracted`	`contracted`	`planned` (WABA هيٺ التواء)	`planned` (Phase 4، `/specs/sd/08-integrations-spec/` §12.4)	`planned` (PWA، Phase 1+)
حاصل ڪري ٿو	`FR-MCI-001`	`FR-MCI-002`	`FR-MCI-002`	`FR-MCI-003`	`FR-MCI-004`

ويب فارم (channel_of_origin = web) ۽ پبلڪ API (channel_of_origin = api) اهي بنيادي چينلز آهن جيڪي /specs/sd/06-ticket-workflow/ ۽ /specs/sd/12-api-contract/ ۾ دستاويز ٿيل آهن؛ انجسٽ کان پوءِ اهي ساڳئي پائپ لائن ۾ شامل ٿين ٿا ۽ هتي ٻيهر متعين ناهن ٿيل.

5. هر چينل جي تفصيل

هر چينل کي /specs/sd/08-integrations-spec/ §3 جي انٽيگريشن ٽيمپليٽ جي خلاف بيان ڪيو ويو آهي ته جيئن معاهدا مقابلي پذير هجن. جتي بنيادي ٽرانسپورٽ اڳ ۾ ئي /specs/sd/08-integrations-spec/ §5 ۾ متعين آهي (Mailjet، SMS، WhatsApp)، هي سيڪشن صرف ان تي رکيل انٽيڪ مخصوص رويي جو احاطو ڪري ٿو.

5.1 اي ميل کان ٽڪيٽ

خانو	قدر
مقصد	سهولت ڊيسڪ پتي تي اي ميل ذريعي شكايتون، فالو اپس، ۽ ثبوت وصول ڪريو؛ هر ان باؤنڊ کي نئون ٽڪيٽ يا منسلڪ جواب بڻايو؛ منسلڪات محفوظ رکو.
سمٽ	ان باؤنڊ (Mailjet ان باؤنڊ parse → SITP) ٻه طرفن جوابن سان (آفيسر اي ميل سان جواب ڏئي ٿو ته ساڳئي ٽڪيٽ ٿريڊ سان منسلڪ ٿئي ٿو).
تصدیقي طريقو	Mailjet ان باؤنڊ تي DKIM/SPF تصديق ڪري ٿو؛ SITP ميljet ويب هوڪ دستخط جي تصديق ڪري ٿو (`08-integrations-spec` §5.1).
ان باؤنڊ پتو	`facilitation@sindhitportal.maahir.io` (عام انٽيڪ) ۽ هر ٽڪيٽ لاءِ `ticket-<trackingId>@inbound.sindhitportal.maahir.io` (جواب روٽنگ، `§7` ڏسو).
اهم آپريشنز	`onInboundEmail` (پيدا ڪريو يا منسلڪ ڪريو)، موضوع ٽريڪنگ آءِ ڊي يا `In-Reply-To`/`References` تي ٿريڊ ميچ، منسلڪات AV-scan.
ٿريڊنگ	(1) جيڪڏهن `In-Reply-To`/`References` هيڊر ڪنهن ٽريڪ ٿيل آؤٽ باؤنڊ پيغام کي حل ڪري ٿو → منسلڪ ڪريو. (2) ورنہ جيڪڏهن موضوع ۾ ٽريڪنگ آءِ ڊي regex `SITP-\d{4}-[A-Z]{3,5}-\d{6}` هجي → منسلڪ ڪريو. (3) ورنہ → ڊي ڊپ چيڪ → `§3.3` مطابق پيدا ڪريو يا منسلڪ ڪريو.
موضوع → عنوان	موضوع جي پهرين غير خالي، غير-"Re:"/"Fwd:" لائين؛ AI وضاحت لاءِ `title` ۾ ٻيهر لکي سگهي ٿو جڏهن ته `subject_raw` محفوظ رکي.
باڊي → تفصيل	quote ٿيل جوابن ۽ دستخط بلاڪن کان پاڪ؛ اصلي HTML/plain کي `body_raw` طور محفوظ رکيو ويندو آهي.
منسلڪات	ڪڍيا ويندا آهن، AV-scanned، encrypted اسٽور ٿيندا آهن (`FR-FILE-003`، `FR-FILE-004`)؛ مسترد قسوم لاگ ٿينديون آهن.
تصدیق	ساڳئي ٿريڊ تي ٽريڪنگ آءِ ڊي ۽ پورٽل URL سان جواب، هر ٽڪيٽ ان باؤنڊ پتي کي `Reply-To` طور استعمال ڪندي ته جيئين ايندڙ جواب ٿريڊ جاري رکي.
اینٽي اِيوز	هر موڪليندڙ جو ريٽ لِمٽ (`§10`)؛ DKIM/SPF ناڪامي → جائزي لاءِ روکڻ (`FR-MCI-007`).
حيثيت	`contracted`.
حاصل ڪري ٿو	`FR-MCI-001`.

5.2 SMS کان ٽڪيٽ

خانو	قدر
مقصد	بنا قابل اعتماد ڊيٽا وارن موڪليندڙن لاءِ گهٽ بينڊوڊٿ انٽيڪ رستو فراهم ڪرڻ — short-code تي هڪ مختصر پيغام ٽڪيٽ بڻجي ٿو يا منسلڪ ٿئي ٿو؛ ٽڪيٽ اطلاع جي جوابن بہ طورِ افسلتہ منسلڪ ٿين ٿا.
سمٽ	ان باؤنڊ (mobile-originated، MO) تائين short-code؛ ٻه طرفو (آؤٽ باؤنڊ SMS جا جواب منسلڪ ٿين ٿا).
تصدیقي طريقو	MSISDN سڃاڻپ جو اشارو آهي (SIM-bound)؛ ايگريگيٽر ڊليوري رسيدن تي دستخط ڪري ٿو؛ SITP هر MSISDN تي ريٽ لِمٽ لڳائي ٿو.
short-code ۽ ڪنجي لفظ	هڪ مخصوص short-code (مثلاً `82547`) قبول ڪري ٿو: `SITP <free-text complaint>` داخل ڪرڻ لاءِ؛ `SITP STATUS <trackingId>` حيثيت پڇڻ لاءِ؛ ڪنهن به آؤٽ باؤنڊ ٽڪيٽ SMS جو سادو جواب بہ طورِ افسلتہ منسلڪ ٿئي ٿو.
گهٽ بينڊوڊٿ معاهدو	ڇوته SMS باڊي شاذ و نادر ئي ڪافي ثبوت هوندي آهي، هر بڻيل ٽڪيٽ هڪ هڪ ڀيرو استعمال ٿيندڙ مختصر لنڪ (مثلاً `https://sindhitportal.maahir.io/t/<token>`) رکي ٿو جيڪو موبائيل ويب فارم ڏانهن وٺي وڃي ٿو جتي موڪليندڙ تفصيلون، منسلڪات، ۽ CNIC شامل ڪري سگهي ٿو؛ لنڪ configurable ونڊو کان پوءِ ختم ٿي وڃي ٿو ۽ هڪ ڀيرو استعمال ٿئي ٿو.
اینڪوڊنگ	UR/SD کي UCS-2 (70 ڪرڪٽرز/سيگمنٽ) طور موڪليو ويندو آهي؛ EN کي GSM-7 (160 ڪرڪٽرز/سيگمنٽ)؛ concatenate سيگمنٽس parsing کان اڳ ٻيهر جوڙيا ويندا آهن.
ٿريڊنگ	جيڪڏهن MO ڪنهن ٽريڪ ٿيل آؤٽ باؤنڊ SMS جو جواب آهي (ايگريگيٽر پيغام آءِ ڊي سان ميچ) → منسلڪ ڪريو. ورنہ → ڊي ڊپ → پيدا ڪريو يا منسلڪ ڪريو.
تصدیق	جواب SMS ٽريڪنگ آءِ ڊي + مختصر لنڪ کڻي؛ سيگمنٽ ڳڻت لاگ ٿيندي آهي براءِ لاگت تجزيو.
اینٽي اِيوز	هر MSISDN جون روزانو/گهنٽي جون ڪيپس (`§10`)؛ بنا ڪنجي لفظ يا بي معنيٰ باڊيز جائزي لاءِ روڪيون وينديون آهن.
حيثيت	`contracted` (SMS گیٽوي اسٽيڪ-لاڪڊ؛ short-code الاٽمينٽ هڪ خريداري انحصار آهي).
حاصل ڪري ٿو	`FR-MCI-002`.

5.3 WhatsApp کان ٽڪيٽ

خانو	قدر
مقصد	ان چينل تي شڪايتون، ثبوت، ۽ وائس نوٽس وصول ڪريو جيڪو IT ڪمپنيون روزانو استعمال ڪن ٿيون؛ ميڊيا محفوظ رکو؛ ٻه طرفي ڳالهه ٻولهه فراهم ڪريو جيڪا ٽڪيٽ ٿريڊ سان منسلڪ ٿئي.
سمٽ	ان باؤنڊ (Cloud API ويب هوڪ) + ٻه طرفو جواب؛ 24 ڪلاڪ ڪسٽمر سروس ونڊو کان ٻاهر اڳ ۾ منظور ٿيل ٽيمپليٽن ذريعي آؤٽ باؤنڊ.
تصدیقي طريقو	`X-Hub-Signature-256` (HMAC-SHA256) تصديق ٿيل (`08-integrations-spec` §5.3)؛ موڪليندڙ جو فون WA-verified آهي ۽ ٽيمپليٽ پيغام وصول ڪرڻ لاءِ opt-in ڪرڻ ضروري آهي.
اهم آپريشنز	`onMessage` (text/image/document/voice/video)، `onMessageStatus`، opt-in/opt-out.
ميڊيا هيندلنگ	ان باؤنڊ ميڊيا Cloud API مان ڊائون لوڊ ٿئي ٿو، AV-scanned، encrypted اسٽور ٿئي ٿو؛ image/PDF تي OCR (`FR-AI-001`) ٿئي ٿو؛ وائس نوٽس STT ذريعي transcribe ٿين ٿا (`§5.4` انجن ٻيهر استعمال) ۽ transcript تفصيل طور اسٽور ٿئي ٿو جڏهن ته آڊيو منسلڪ رهي ٿو.
ٿريڊنگ	`replyContext` (حاليا آؤٽ باؤنڊ ٽيمپليٽ مان parse ٿيل ٽريڪنگ آءِ ڊي) → منسلڪ ڪريو. ورنہ → ڊي ڊپ → پيدا ڪريو يا منسلڪ ڪريو.
Opt-in	ڪنهن به آؤٽ باؤنڊ ٽيمپليٽ کان اڳ موڪليندڙ پاران واضح طور opt-in ڪرڻ ضروري آهي؛ non-opted-in موڪليندڙ جو ان باؤنڊ پيغام ٽڪيٽ ۽ هڪ وصولي تصديق بڻجي ٿو پر انهن کي جاري ٽيمپليٽ موڪلڻ جي خودڪار سبسڪرپشن ناهي ڪندو.
تصدیق	اڳ ۾ منظور ٿيل ٽيمپليٽ (`ticket_created_<locale>` / `ticket_updated_<locale>`) ٽريڪنگ آءِ ڊي + پورٽل URL کڻي.
اینٽي اِيوز	هر فون ريٽ لِمٽس (`§10`)؛ Meta پنهنجن اینٽي اسپيم اشارن جو احترام؛ opted-out موڪليندڙ آؤٽ باؤنڊ متحرڪ ناهي ڪري سگهندا.
حيثيت	`planned` — WABA منظوري + ٽيمپليٽ منظوريون هيٺ التواء (`08-integrations-spec` §12.2).
حاصل ڪري ٿو	`FR-MCI-002`.

5.4 ٽول فري IVر / وائس

خانو	قدر
مقصد	ٽول فري، اسمارٽ فون کان سواءِ انٽيڪ رستو فراهم ڪرڻ؛ شڪايتن کي وائس رڪارڊنگن طور حاصل ڪريو، انهن کي transcribe ڪريو، ٽڪيٽ ٺاهيو؛ ڪالرز کي آءِ ڊي سان موجوده ٽڪيٽ جي حيثيت ڳولهڻ ڏيو؛ جڏهن ايجنٽ دستياب ناهي ته ڪال بیک قطار.
سمٽ	ان باؤنڊ (PSTN → IVر → SITP ڪال بیک) + آؤٽ باؤنڊ (SMS تصديق، شيڊيولڊ وائس ڪال بیک).
تصدیقي طريقو	ڪالر آءِ ڊي (MSISDN) سڃاڻپ جو اشارو آهي؛ CNIC کي وڌيڪ اعتماد وارن قدمن لاءِ DTMF ذريعي حاصل ڪري سگهجي ٿو.
نمبر	هڪ واحد ٽول فري نمبر (مثلاً `0800-SITP`) پبلڪ سائيٽ ۽ سڀني چينل فوٽرن تي شايع ٿيل.
IVر ڪال فلو	(1) ڪالر جي چونڊيل ٻولي ۾ سلام (DTMF سان چونڊيل EN/UR/SD). (2) مينيو: `1` شڪايت داخل ڪريو · `2` ڪنهن موجوده ٽڪيٽ جي حيثيت · `3` ڪنهن سهولت ڪار سان ڳالهه ڪريو · `0` ٻيهر. (3a) شڪايتن لاءِ: prompt → رڪارڊ (configurable وڌ کان وڌ دورانيو، مثلاً 3 منٽ) → تصديق ۽ اختتام. (3b) حيثيت لاءِ: ڪالر DTMF ذريعي ٽريڪنگ آءِ ڊي داخل ڪري ٿو يا ڳالهائي ٿو → نظام موجوده حيثيت + SLA حالت پڙهي ٿو. (3c) سهولت ڪار لاءِ: جيڪڏهن ڪو ايجنٽ دستياب ناهي ته ڪال بیک قطار ۾ داخل ٿيو؛ ڪال بیک سلاٽ جي پيشڪش.
اسپيچ ٽو ٽيڪسٽ	رڪارڊنگ STT انجن (pluggable، AI/OCR سروس سان گڏ فراهم ڪندڙ خاندان) ذريعي transcribe ٿئي ٿي؛ transcript ٽڪيٽ جي تفصيل بڻجي ٿو؛ آڊيو فائل ثبوت طور منسلڪ ٿئي ٿي. مينوئل فال بیک: گهٽ اعتماد وارا transcripts ٽڪيٽ بڻجڻ کان اڳ تصديق لاءِ سهولت ڪار ڏانهن موڪليا ويندا آهن.
ٻولي سڃاڻپ	ڪالر جي بيان ڪيل ٻولي prompts هلائيندي آهي؛ STT گهٽ اعتماد تي بيان ڪيل ٻولي تي خودڪار فال بیک سان EN/UR/SD سپورٽ ڪري ٿو.
تصدیق	ڪالر ڏانهن SMS نئون ٽريڪنگ آءِ ڊي ۽ منسلڪات/CNIC شامل ڪرڻ جي مختصر لنڪ سان (`§5.2` جي هم مرتبہ).
حيثيت look up	صرف پبلڪ حيثيت جون معلومات پڙهي ٿو (`FR-TKT-006`)؛ فون تي ڪالر جي ڏنل معلومات کان وڌيڪ ڪابه PII ناهي پڙهي ويندي.
ڪال بیک قطار	ڪالر MSISDN، بيان ڪيل ٻولي، ۽ ترجيحي سلاٽ سان هيٺ التواء ڪال بیکس جي BullMQ قطار؛ دستياب سهولت ڪار ايندڙ ڪال بیک claim ڪري ٿو ۽ نظام آؤٽ باؤنڊ ڪال لڳائي ٿو.
اینٽي اِيوز	هر MSISDN ريٽ لِمٽس (`§10`)؛ ضرورت کان وڌيڪ مختصر ڪالز ڇڏيون وينديون آهن؛ بدتميز ڪالرز جائزي لاءِ نشان زد ٿيندا آهن.
حيثيت	`planned` — `/specs/sd/08-integrations-spec/` §12.4 مطابق Phase 4 (ٽول فري نمبر، IVر پليٽ فارم، STT معاهدو ضروري).
حاصل ڪري ٿو	`FR-MCI-003`.

5.5 پيرين / آف لائن اندراج

خانو	قدر
مقصد	هڪ فرنٽ ڊيسڪ / فيلڊ آفيسر کي ڪنهن پيرين ايندڙ زائر يا فيلڊ ۾ ملندڙ شهري جي طرفان شڪايت داخل ڪرڻ ڏيو، زائر جي سڃاڻپ، شڪايت، ۽ ڪابه به ثبوت حاصل ڪندي؛ آفيسر کي منسوب ايڪٽر طور رڪارڊ ڪريو؛ ڪنيڪٽيوٽي واپس اچڻ تي سنڪ.
سمٽ	PWA (آن لائن) يا PWA آف لائن قطار (سنڪ بيچ) ذريعي ان باؤنڊ.
تصدیقي طريقو	آفيسر OIDC ذريعي PWA ۾ مصدق ٿئي ٿو (`08-integrations-spec` §7) S&ITD/پارٽنر سهولت ڪائونٽرن لاءِ Filer جي هم مرتبہ انٽيڪ اجازت سان؛ حساس ٽڪيٽن لاءِ step-up تصديق (`FR-ORG-009`) ضروري.
حاصل ڪرڻ جا خانا	زائر جي سڃاڻپ (نالو، CNIC اختياري، فون، اي ميل اختياري)، جنهن تنظيم جي طرفان (نالو/CNIC/SECP نمبر سان lookup، يا غير ڪمپني پيرين اچڻ وارن لاءِ `individual`)، عنوان، تفصيل، قسم (آفيسر جي مدد)، منسلڪات (ڪيمرا/دستاويزون).
منسوب	هر پيرين ٽڪيٽ `channel_of_origin = walkin`، `entered_by = <officerId>`، ۽ `on_behalf_of = <visitorId
آف لائن رويو	PWA اندراج کي اصلي اندراج ٽائم اسٽيمپ سان IndexedDB ۾ اسٽور ڪري ٿو؛ ڊوائيس پے لوڊ کي آفيسر جي session سان دستخط ڪري ٿو؛ ٻيهر ڪنيڪٽ ٿيڻ تي، هڪ سنڪ بيچ پوسٽ ٿئي ٿو ۽ هر اندراج معياري پائپ لائن مان لنگهي ٿو (ڊي ڊپ اڃا تائين بيچ ۽ موجوده ٽڪيٽن جي خلاف لاڳو ٿئي ٿو). تضاد (ساڳئي زائر انهيءَ دوران آن لائن داخل ڪرايو) آفيسر کي ڏيکاريا ويندا آهن.
تصدیق	ڪائونٽر تي زائر جو چونڊيل چينل — SMS، WhatsApp، اي ميل، يا ٽريڪنگ آءِ ڊي کڻندڙ پرنٽ ٿيل رسید.
اینٽي اِيوز	بلڪ پيرين فلڊنگ روڪڻ لاءِ هر آفيسر جو ريٽ لِمٽ (`§10`)؛ غير معمولي حجم وارا آفيسر نگران جائزي لاءِ نشان زد ٿيندا آهن.
حيثيت	`planned` (PWA پهريان → پوءِ React Native `_context.md` §3 مطابق).
حاصل ڪري ٿو	`FR-MCI-004`.

6. ان باؤنڊ پيغام → ٽڪيٽ فيلڊ ميپنگ

هر ان باؤنڊ پيغام، چينل کان قطعِ نظر، انهيءَ ئي معياري ٽڪيٽ ماڊل تي ميپ ٿئي ٿو (/specs/sd/05-data-model/ ڏسو). هيٺ جي جدول مستند فيلڊ ميپ آهي. جتي ڪنهن چينل وٽ ڪنهن فيلڊ لاءِ ڪابه مقامي قدر ناهي هوندي، پائپ لائن ان کي AI (§3.3 مرحلو 5) مان ڀريندي آهي يا ٽرائج لاءِ ڇڏ ڏيندي آهي.

ٽڪيٽ فيلڊ	اي ميل ماخذ	SMS ماخذ	WhatsApp ماخذ	IVر / وائس ماخذ	پيرين ماخذ
`channel_of_origin`	`email`	`sms`	`whatsapp`	`ivr`	`walkin`
`title`	موضوع (صاف ٿيل)	باڊي جا پهريا ~80 ڪرڪٽرز، AI ٻيهر لکيل	پهرين لائين / AI خلاصو	transcript جو AI خلاصو	آفيسر جو داخل ڪيل
`description`	باڊي (پاڪ ٿيل)	مڪمل MO باڊي + short-link نوٽ	متن + ڪابه به وائس نوٽ جو transcript	STT transcript (آڊيو منسلڪ)	آفيسر جو داخل ڪيل
`requested_by` (rep)	اي ميل → rep/org ميچ، ورنہ عارضي (`§7`)	MSISDN → rep/org/CNIC ميچ، ورنہ عارضي	فون → rep/org ميچ، ورنہ عارضي	MSISDN → rep/org ميچ، ورنہ عارضي	آفيسر چونڊيل org/rep يا عارضي زائر
`entered_by` (ايڪٽر)	—	—	—	—	آفيسر آءِ ڊي
`on_behalf_of`	—	—	—	—	زائر جي سڃاڻپ
`category`	AI تجويز → ٽرائج تصديق	AI تجويز → ٽرائج تصديق	AI تجويز → ٽرائج تصديق	AI تجويز → ٽرائج تصديق	آفيسر جو داخل ڪيل + AI تجويز
`target_dept` / `section`	AI روٽنگ تجويز (`FR-AI-003`)	اهو ئي	اهو ئي	اهو ئي	اهو ئي
`priority` / `urgency`	AI فوريت (`FR-AI-004`)	اهو ئي	اهو ئي	اهو ئي	اهو ئي
`locale`	باڊي اسڪرپٽ + Accept-Language	UCS-2 سڃاڻپ → `ur`/`sd`/`en`	متن/وائس ٻولي سڃاڻپ	ڪالر جي بيان ڪيل + STT	PWA فارم لوڪيل
`attachments[]`	اي ميل منسلڪات (AV-scanned)	—	WA ميڊيا (AV-scanned)	وائس رڪارڊنگ (آڊيو)	آفيسر اپ لوڊ ڪيل (AV-scanned)
`subject_raw` / `body_raw`	اصلي هيڊرز + خام باڊي	خام MO PDU	خام ويب هوڪ پے لوڊ	خام ڪال ميٽا ڊيٽا	خام فارم پے لوڊ
`inbound_ref`	Mailjet پيغام آءِ ڊي	ايگريگيٽر MO آءِ ڊي	WA پيغام آءِ ڊي	IVر ڪال آءِ ڊي	PWA سنڪ بيچ + اندراج UUID
`thread_target`	`In-Reply-To`/References يا ٽريڪنگ آءِ ڊي سان حل	reply-context سان حل	`replyContext` سان حل	(لاڳو ناهي — هميشه نئون)	(لاڳو ناهي — هميشه نئون)
`redaction_map_ref`	آن پريميس حذف جو نقشو handle	اهو ئي	اهو ئي	اهو ئي	اهو ئي
`sla_tier`	محڪمو/قسم/فوريت ڪنفيگر مان (`FR-TKT-007`)	اهو ئي	اهو ئي	اهو ئي	اهو ئي
`created_at`	وصولي ٽائم اسٽيمپ	MO ٽائم اسٽيمپ	ويب هوڪ ٽائم اسٽيمپ	رڪارڊنگ اختتام ٽائم اسٽيمپ	اصلي اندراج ٽائم اسٽيمپ (آف لائن سنڪ تي محفوظ)

ان باؤنڊ چينلز مان بڻيل ٽڪيٽ ڊيٽا ماڊل ۾ ويب/API ٽڪيٽن کان نا مميز هوندا آهن؛ ڊائون اسٽريم SLA، اسڪيليشن، حل جو ثبوت، ۽ تجزياتي منطق channel_of_origin تي شاخ ناهي کوليندڙ.

7. سڃاڻپ منسلڪ ڪرڻ

ان باؤنڊ پيغام شاذ و نادر ئي ڪنهن لاگ اِن ٿيل session رکندا آهن؛ اهي هڪ چينل سڃاڻپ (اي ميل پتو، MSISDN، WA-verified فون، ڪالر آءِ ڊي، CNIC) رکندا آهن. پائپ لائن ٽڪيٽ بڻجڻ کان اڳ (MC-2) ان سڃاڻپ کي ڪنهن موجوده تنظيم / نمائندي سان حل ڪري ٿي، يا هڪ عارضي سڃاڻپ ٺاهي ٿي.

7.1 حل جي ترتيب

سڃاڻپ منسلڪ ڪرڻ واري سروس، جيڪا نارملائيز مرحلي تي سڏبي آهي، هن ترجيحي ترتيب ۾ حل جي ڪوشش ڪري ٿي:

بالڪل rep ميچ — ان باؤنڊ سڃاڻپگر ڪنهن نمائندي جي رجسٽرڊ اي ميل يا فون سان ميچ (org_rep جدول). |
تنظيم ڊومين ميچ — اي ميل لاءِ، موڪليندڙ جو ڊومين ڪنهن رجسٽرڊ تنظيم جي تصديق ٿيل ڊومين سان ميچ (file-first domain-email اشارو، _context.md §5). |
CNIC ميچ — ان باؤنڊ CNIC ظاهر ڪري ٿو يا کڻي اچي ٿو (IVر DTMF، پيرين آفيسر اندراج، پيغام باڊي PII سڃاڻپ مان نڪتل) جيڪو ڪنهن نمائندي جي CNIC سان ميچ. |
عارضي سڃاڻپ — ڪابه ميچ ناهي ملي؛ چينل سڃاڻپگر سان گڏ هڪ Provisional موڪليندڙ رڪارڊ بڻجي ٿو، unverified نشان زد، ۽ ٽڪيٽ ان کي منسوب ٿئي ٿو. موڪليندڙ کي رجسٽريشن جي دعوت ڏني ويندي آهي؛ ڪامياب رجسٽريشن تي، عارضي سڃاڻپ نئين rep ۾ ضم ٿي ويندي آهي ۽ ٽڪيٽ ٻيهر منسوب ٿئي ٿو. |

7.2 سڃاڻپ جو جدول

ميچ جو نتيجو	ٽڪيٽ منسوب	بعد جو رويو
بالڪل rep	`requested_by = rep`؛ org inherited	مڪمل RBAC لاڳو؛ rep ٽڪيٽ پنهنجي پورٽل ۾ ڏسندو آهي.
ڊومين ميچ	`requested_by = Provisional (domain)`؛ org منسلڪ	رجسٽريشن جي دعوت؛ رجسٽر ٿيڻ تي، rep وارث.
CNIC ميچ	`requested_by = rep` (CNIC-confirmed)	step-up اعتماد؛ حساس قدمن لاءِ اهل.
ڪابه ميچ ناهي (عارضي)	`requested_by = Provisional`؛ org = `individual` يا نامزد	ٽڪيٽ اڳتي وڌندو آهي؛ رجسٽريشن دعوت موڪلي وئي؛ رجسٽر ٿيڻ تي ضم.

سڃاڻپ منسلڪ ڪرڻ صرف نارملائيز مرحلي تي سڃاڻپ جي جداول جي خلاف read/write آهي؛ بعد وارا مرحلا حل ٿيل سڃاڻپ پائپ لائن سياق مان پڙهندا آهن. ان سان PII هيندلنگ هڪ ئي آڊٽ ٿيل جاءِ تي رهي ٿي.

8. چينل کان آزاد روٽنگ

هڪ ڀيرو ٽڪيٽ بڻجڻ کان پوءِ، روٽنگ چينل کان قطعِ نظر متساوي آهي (MC-4). AI روٽنگ تجويز (FR-AI-003) ۽ محڪمو/قسم ڪنفيگريشن هدف محڪمو ۽ سيڪشن هلائيندي آهي، بالڪل ويب ٽڪيٽن جيان (/specs/sd/06-ticket-workflow/ §4–§5 ڏسو). واحد چينل آگاه رويو فال بیک تصديق (§12) آهي.

ٻه ضمانتون لاڳو ٿينديون آهن:

ڪنهن گهٽ بينڊوڊٿ چينل (SMS، IVر) مان بڻيل ٽڪيٽ روٽنگ يا SLA ۾ ان لاءِ سزا ناهي پائيندو ته ان ۾ ڊگهي تفصيل ناهي. AI خلاصو + آفيسر ٽرائج روٽنگ حتمي ٿيڻ کان اڳ تفصيل ۾ اضافو ڪن ٿا؛ FRT گهڙي ٽرائج مڪمل ٿيڻ تائين شروع ناهي ٿيندي (/specs/sd/06-ticket-workflow/ §2 ۾ New → Triaged → Assigned ماڊل مطابق).
ڪنهن عارضي موڪليندڙ (§7) مان بڻيل ٽڪيٽ عام طور روٽ ٿئي ٿو؛ تصديق جي حيثيت ٽرائج کي ناهي روڪيندڙ (file-first / verify-in-parallel، _context.md §5).

9. گهڻ لساني ان باؤنڊ

پورٽل EN/UR/SD کي locked ٻوليون طور پيش ڪري ٿو (_context.md §2). ان باؤنڊ پيغام انهن مان ڪنهن به هڪ (۽ ڪڏهن ڪڏهن مليل يا translitered شڪلن) ۾ اچن ٿا. پائپ لائن ان کي ٽن مرحلن ۾ سنڀاليندو آهي:

مرحلو	رويو
سڃاڻپ	ٻولي سڃاڻپ AI-درجه بندي مرحلي تي هلندي آهي؛ اسڪرپٽ (Latin / Nastaliq / Naskh) ۽ اعتماد اسڪور منسلڪ ڪيا ويندا آهن. مليل ٻولي وارا پيغام غالب ٻولي سان گڏ ٽيگ ۽ نشان زد ٿيندا آهن.
اسٽور	اصلي پيغام تبديل ڪيا بنا محفوظ ڪيو ويندو آهي (`locale_detected`)؛ ڪو به ترجمو تفصيل طور اسٽور ناهي ٿيندو — اهو آفيسر سان گڏ پيش ڪيو ويندو آهي.
ترجمو	تفويض ٿيل آفيسر لاءِ، هڪ آن ڊيمانڊ AI ترجمو (`FR-AI-006`) اصلي سان گڏ، مشين پيدا ٿيل واضح نشان زد، آفيسر جي ڪم واري ٻولي ۾ ڏيکاريو ويندو آهي. آفيسر متبادل جملہ بندي گهرجي سگهي ٿو؛ اصلي ڪڏهن overwrite ناهي ٿيندڙ.

IVر ڪال جي شروعات تي هڪ ڪالر جي بيان ڪيل ٻولي شامل ڪري ٿو؛ IVر prompts ۽ STT انجن ان کي خودڪار فال بیک سان بنيادي ٻولي طور استعمال ڪن ٿا. پيرين آفيسر ڪائونٽر تي فارم لوڪيل چونڊيندا آهن؛ جيڪڏهن زائر ڪنهن ٻي ٻولي ۾ املا ظاهر ڪري، ته آفيسر جو رڪارڊ ٿيل متن سنڪ تي ٻولي سڃاڻپ مان لنگهندو آهي.

10. ريٽ لِمٽنگ ۽ اينٽي اِيوز

ان باؤنڊ انٽيڪ هڪ کُللي سطح آهي؛ کيس جائز موڪليندڙن کي بنا روڪ سپيم، فلڊنگ، ۽ اِيوز جو مقابلو ڪرڻ گهرجن (FR-MCI-007، _context.md §6). ڪنٽرول تہه در تہه آهن:

تہه	دائرو	ڊفالٽ (configurable)	خلاف ورزي تي اقدام
هر ماخذ ريٽ لِمٽ	هر اي ميل / MSISDN / WA فون	≤ 10 ان باؤنڊ/گهنٽو، ≤ 50/روز	ٿروٽل (اضافي ڇڏيو، 1 "rate-limited" نوٽس/روز موڪليو)
هر IP ريٽ لِمٽ	ويب/API ان باؤنڊ	600 req/min read، 60/min create (`/specs/sd/08-integrations-spec/` §8.1 مطابق)	429 `Retry-After` سان
هر آفيسر ريٽ لِمٽ	پيرين آفيسر	≤ 100 اندراج/روز	نرم ڪيپ؛ نگران کي مطلع
DKIM/SPF / WA دستخط	اي ميل ان باؤنڊ	ضروري	ناڪامي → سهولت ڪار جائزي لاءِ روکڻ (`FR-MCI-007`)
ڪنجي لفظ / مواد فلٽر	SMS، WA	داخل ڪرڻ لاءِ ڪنجي لفظ ضروري (مثلاً `SITP`)	غير ڪنجي لفظ پيغام جائزي لاءِ روڪيا ويندا آهن
فلڊ سڃاڻپ	هر ماخذ burst	60 سيڪنڊ ۾ > حد	عارضي بلاڪ (5–60 منٽ) + جائزو قطار
اسپيم درجه بندي	سڀ چينلز	AI اسپيم اسڪور	وڌيڪ اسڪور وارا ان باؤنڊ قرنطينه؛ سهولت ڪار جائزو وٺندو آهي؛ جائز رهاز اصلي ٽائم اسٽيمپ سان ٽڪيٽ بڻائي ڇڏيندا آهن
موڪليندڙ جي ساک	هر سڃاڻپگر تي مستقل	سٺي رويي تي ڪمزور	گهٽ ساک وارن موڪليندڙن جو ان باؤنڊ هميشه جائزي لاءِ روکيو ويندو آهي
CAPTCHA / step-up	پبلڪ حيثيت lookup (`FR-TKT-006`)	N غلط ڪوششن کان پوءِ	CAPTCHA-gated؛ وڌيڪ اِيوز → IP ريٽ لِمٽ

هر ريٽ لِمٽ ۽ اينٽي اِيوز فيصلو فائر ٿيل rule سان گڏ آڊٽ لاگ ٿيندو آهي. روڪيل/قرنطينه ان باؤنڊ شيفت تي موجود سهولت ڪار جي جائزو قطار ۾ ظاهر ٿيندا آهن؛ ڪنهن شيءِ کي آزاد ڪرڻ مرحلو 3 کان اڳتي باقي پائپ لائن مان لنگهندو آهي.

11. چينلز جي وچ ۾ ڊي ڊپ ۽ ضم

هڪ شڪايت ڪندڙ صبح اي ميل سان ۽ ٻيپهري WhatsApp سان ساڳيو مسئلو داخل ڪري سگهي ٿو؛ ساڳئي ڪمپني جو ڪو ساٿي هڪ گهنٽي پوءِ SMS ڪري سگهي ٿو. نظام کي اهو سڃاڻڻ ۽ ضم ڪرڻ جي تجويز ڪرڻ گهرجن، خاموشي سان خودڪار ضم ڪڏهن ناهي (FR-MCI-005، FR-TKT-015).

11.1 سڃاڻپ جا اشارا

اشارو	وزن	نوٽس
ساڳيو حل ٿيل سڃاڻپ (rep/org)	وڌيڪ	`§7` حل کان پوءِ.
ساڳيو MSISDN/اي ميل/CNIC (ڪراس چينل)	وڌيڪ	WhatsApp مان فون + اي ميل مان اي ميل = ساڳيو شخص جيڪڏهن CNIC ميچ ڪري ٿو.
ساڳئي تنظيم + مماثل قسم	وچولو	ساڳئي ڪمپني، ساڳيو مسئلو خاندان.
عنوان/تفصيل جي متن مماثلت (`FR-AI-007`)	وچولو	حد tuned؛ Confidential/VIP scope جو احترام.
وقت ۾ قربت	گهٽ (ٽاءِ بريڪر)	ساڳيو ڏينهن بمقابله ساڳيو سال.
ساڳيو منسلڪ هيش	وچولو	چينلز تي هڪجهڙائي ثبوت فائل.

11.2 ضم جو فيصلو

ڊي ڊپ چيڪ (پائپ لائن مرحلو 4) اميدوار ميچ مماثلت اسڪورن سان موٽائي ٿو. ٽرائج آفيسر فيصلو ڪندو آهي:

نئين طور اڳتي وڌو — ڪابه ضم ناهي؛ انتخاب آڊٽ لاگ ٿئي ٿو. |
منسلڪ ڪريو — FR-TKT-017 مطابق هڪ typed relation (related to، duplicate of) ٺاهيو؛ ٻئي ٽڪيٽ آزادانه طور ٽريڪ رهندا آهن. |
ضم ڪريو — FR-TKT-015 مطابق نئين ٽڪيٽ کي پراڻي (يا آفيسر جي چونڊيل پرائمري) ۾ سڻيٽيو: ثانوي locked، منسلڪات/تبصرا/watchers پرائمري تي consolidate، فائل ڪندڙ کي پرائمري جي ٽريڪنگ آءِ ڊي سان مطلع ڪيو ويندو آهي. |

11.3 ڊي ڊپ ۽ ضم فلو

خاڪو ڊي ڊپ فيصلي کي ٽرائج آفيسر مان هلندڙ state machine طور ڏيکاري ٿو.

stateDiagram-v2 [*] --> Detected: dedup check finds candidates Detected --> Surfaced: candidates + scores on triage view Surfaced --> ProceedNew: officer: "new" Surfaced --> Linked: officer: "link" Surfaced --> Merged: officer: "merge" ProceedNew --> [*]: audit-logged, ticket routes normally Linked --> [*]: FR-TKT-017 relation created Merged --> Consolidating: choose primary Consolidating --> Locked: secondary locked Consolidating --> Consolidated: attachments/comments/watchers moved Locked --> Consolidated Consolidated --> Notified: filer told primary ID Notified --> [*]

12. فال بیک چين ۽ ڪراس چينل لچڪ

هر چينل ڪنهن ٽين پارٽي فراهم ڪندڙ (Mailjet، SMS ايگريگيٽر، Meta، IVر/PSTN ڪيريئر، ۽ — پيرين لاءِ — آفيسر جي ڪنيڪٽيوٽي) تي منحصر آهي. ان باؤنڊ انٽيڪ لاءِ ڪنهن به واحد فراهم ڪندڙ کي سخت انحصار بڻجڻ جي اجازت ناهي، ۽ تصديق جي ترسيل کي هميشه ڪم ڪندڙ رستو ملڻ گهرجن.

تشوش	لچڪ جو طريقو ڪار
ان باؤنڊ ingestion	هر چينل جو پنهنجو ريسيور ۽ قطار آهي؛ هڪ فراهم ڪندڙ بند ٿيڻ سان باقي چار بلاڪ ناهي ٿيندا. انٽيڪ پائپ لائن مرحلو 1 کان پوءِ فراهم ڪندڙ کان آزاد آهي.
تصدیق ترسيل	هر موڪليندڙ لاءِ هڪ فال بیک چين پهرين اصلي چينل آزمايي ٿي، پوءِ موڪليندڙ جا ٻيا معلوم چينلز (ترجيح جي ترتيب ۾: WhatsApp → SMS → اي ميل → in-app)، پهرين ڪامياب ack تي رڪندي ٿي. ترجيح هر موڪليندڙ ۽ پيغام ڪلاس لاءِ configurable آهي.
فراهم ڪندڙ سرڪٽ بريڪر	هر ايڊاپٽر بريڪر (`08-integrations-spec` §2.1)؛ کُليل هجڻ تي، ان چينل جو آؤٽ باؤنڊ فال بیک چين ۾ short-circuit ۽ ops کي الرٽ.
DLQ ۽ ري پلے	جيڪي تصديقون retries ختم ڪن تنهن هر ايڊاپٽر DLQ ۾ وينديون آهن؛ هڪ ورڪر فراهم ڪندڙ بحال ٿيڻ تي انهن کي ري پلے ڪندو آهي، اصلي ٽائم اسٽيمپ محفوظ.
ڪراس فراهم ڪندڙ SMS	Jazz ۽ Telenor ٻئي failover لاءِ معاهدو ٿيل (`08-integrations-spec` §5.2)؛ ناڪام پرائمري ايگريگيٽر پيغام ڪلاس مطابق fail over.
پبلڪ حيثيت	پبلڪ حيثيت صفحو (۽ IVر حيثيت-lookup آپشن `§5.4`) cached aggregate مان پڙهندو آهي، تنهنڪري هڪ چينل تي فراهم ڪندڙ بند ٿيڻ سان پبلڪ اَنڌو ناهي ٿيندڙ.

ڪنهن چينل جو صرف پڙهڻ لاءِ بند (ان باؤنڊ ٺيڪ، آؤٽ باؤنڊ ٽٽل) هجڻ ٽڪيٽ تي ٽرائج آفيسر کي ڏيکاريو ويندو آهي ته جيئن دستي فالو اپ ڪنهن ٻي چينل سان ٿي سگهي.

13. آف لائن / فيلڊ انٽيڪ

پيرين/آف لائن اندراج (§5.5) عملي طور تي سڀ کان وڌيڪ مشڪل چينل آهي ڇوته آفيسر جو ڊوائيس حاصل ڪرڻ جي مقام تي آف لائن ٿي سگهي ٿو. معاهدو:

تشوش	رويو
حاصل ڪرڻ	PWA فارم مڪمل آف لائن ڪم ڪري ٿو؛ اندراج اصلي اندراج ٽائم اسٽيمپ ۽ آفيسر جي دستخط ٿيل session سان IndexedDB ۾ اسٽور ٿيندا آهن.
اسٽوريج حدون	مقامي ڪيپ (مثلاً 200 هيٺ التواء اندراج) ڪيپ جي ويجهو وارننگ؛ سڀ کان پراڻي غير سنڪ ٿيل آفيسر کي ڏيکاري ويندي آهي.
تضاد	جيڪڏهن ساڳئي زائر/عارضي سڃاڻپ آفيسر آف لائن رهڻ دوران آن لائن داخل ڪرايو، ته ڊي ڊپ (`§11`) سنڪ تي پڪڙيندو آهي ۽ تضاد حل لاءِ آفيسر کي ڏيکاريندو آهي.
سنڪ	ڪنيڪٽيوٽي واپس اچڻ تي هڪ بڪ گرائونڊ سنڪ ورڪر بيچ پوسٽ ڪندو آهي؛ هر اندراج معياري پائپ لائن مان لنگهندو آهي؛ بڻيل ٽڪيٽ تي اصلي اندراج ٽائم اسٽيمپ محفوظ رهندو آهي (`FR-MCI-004`)، سنڪ ٽائم اسٽيمپ ناهي.
جزوي سنڪ	سنڪ هر اندراج تي idempotent آهي (idempotency key = PDA اندراج UUID)؛ بيچ جي وچ ۾ نيٽورڪ ڊراپ ايندڙ اندراج کان ٻيهر شروع.
آڊٽ	هر آف لائن اندراج ڊوائيس آءِ ڊي، آفيسر آءِ ڊي، حاصل ڪرڻ جو ٽائم اسٽيمپ، سنڪ ٽائم اسٽيمپ، ۽ چونڊيل ڪابه تضاد حل رڪارڊ ڪندو آهي.
ميڊيا	تصويرون/منسلڪات مقامي طور حاصل ۽ اسٽور ٿينديون آهن، پوءِ سنڪ تي اپ لوڊ ۽ پائپ لائن جي حصي طور AV-scanned.

14. چينل تجزيات

چينلِ اصليت هڪ first-class تجزياتي بُعد آهي (FR-MCI-006). تجزيات ماڊيول (/specs/sd/17-analytics-kpis/) anl_mv_* materialized views مان هيٺيان چينل-scoped ميٽرڪس پيدا ڪندو آهي، RBAC + پبلڪ دٻاءُ جي قاعدن (AP-3، AP-4) جو احترام ڪندي.

ميٽرڪ	grain	سامع	نوٽس
چينل جي لحاظ کان حجم	ڏينهن × محڪمو × چينل	اسٽاف / DG / سيڪريٽري / SACM / پبلڪ (گمنام)	Stacked bar؛ ٽڪيٽن تائين drill-down (AP-2).
وقت سان گڏ چينل mix	هفتو × چينل	قيادت	رجحان؛ چينل-شفٽ نشان زد (مثلاً WhatsApp اي ميل کان اڳتي).
چينل جي لحاظ کان پهريون جواب وقت	ڏينهن × چينل	اسٽاف / DG	`MC-4` (چينل کان آزاد FRT) آزمائي ٿو.
چينل جي لحاظ کان حل جي شرح	مهينو × چينل	قيادت / پبلڪ	جيڪڏهن `MC-4` لاڳو هجي ته تقريبن برابر هجڻ گهرجن؛ فرق تحقيق جو اشارو آهي.
چينل جي لحاظ کان CSAT	مهينو × چينل	اسٽاف / DG	ڪنهن چينل تي گهٽ CSAT بينڊوڊٿ رڪاوٽ (مثلاً SMS) ظاهر ڪري سگهي ٿي.
تبديلي: عارضي → رجسٽرڊ	هفتو × چينل	S&ITD پروڊڪٽ	ڪيترائي ڀيرا پيرين/IVر/SMS فائل ڪندڙ رجسٽر ٿئي ٿو.
ان باؤنڊ تصديق ڪاميابي شرح	ڏينهن × چينل	ops	`§12` فال بیک چين tuning هلائي ٿي.
اسپيم/اِيوز روڪيو	ڏينهن × چينل	ops / ٽرسٽ ۽ سيفٽي	جائزو قطار ۾ حجم (`§10`).
ڊي ڊپ / ضم شرح	هفتو × چينل	S&ITD پروڊڪٽ	ڪيترا ڪراس چينل نقل پڪڙيا وڃن ٿا.
آف لائن-سنڪ lag	ڏينهن × آفيسر	ops	پيرين لاءِ حاصل ڪرڻ ۽ سنڪ جي وچ ۾ وڌ کان وڌ وقت (`§13`).

سڀ چينل ميٽرڪس پنهنجن چينل کان آزاد هم مرتبن سان ساڳيون تعريفون ۽ rounding قاعدا شيئر ڪن ٿا (AP-5)؛ واحد اضافي بُعد channel_of_origin آهي.

15. ڊيٽا ماڊل ٽچ پوائنٽس

هي دستاويز ڊيٽا ماڊل ٻيهر تعين ناهي ڪندي (/specs/sd/05-data-model/ ڏسو) پر پنهنجي انحصار جي ملٽي چينل مخصوص خانن ۽ جداول کي رڪارڊ ڪري ٿي:

جدول / خانو	مقصد	اصليت FR
`tickets.channel_of_origin`	Enum: `web`، `api`، `email`، `sms`، `whatsapp`، `ivr`، `walkin`.	`FR-MCI-006`
`tickets.entered_by`	پيرين لاءِ آفيسر آءِ ڊي؛ ورنہ null.	`FR-MCI-004`
`tickets.on_behalf_of`	پيرين لاءِ زائر/عارضي سڃاڻپ.	`FR-MCI-004`
`tickets.locale_detected`	ان باؤنڊ جي سڃاتل ٻولي.	`§9`
`tickets.inbound_ref`	چينل مخصوص پيغام آءِ ڊي (Mailjet/WA/MO/IVر ڪال/PDA UUID).	`§6`
`tickets.subject_raw` / `body_raw`	اصلي ان باؤنڊ پے لوڊ، محفوظ.	`FR-MCI-001`
`tickets.redaction_map_ref`	PII بحال ڪرڻ لاءِ آن پريميس handle.	`FR-AI-009`
`int_call` (direction = `inbound`)	هر ان باؤنڊ پے لوڊ جو آڊٽ.	`08-integrations-spec` §2.1
`org_rep_channel`	هر rep لاءِ چينل سڃاڻپگر (اي ميل، MSISDN، WA فون).	`§7`
`int_ratelimit`	هر ماخذ/هر آفيسر ريٽ لِمٽ حالت.	`FR-MCI-007`
`ticket_relation`	ڪراس ٽڪيٽ link/merge relations (typed).	`FR-TKT-015`، `FR-TKT-017`
`anl_mv_channel_*`	تجزيات لاءِ چينل-scoped aggregates.	`§14`

16. اينڊ ٽو اينڊ sequence (هڪ ان باؤنڊ → هڪ ٽڪيٽ)

هيٺ ڏنل sequence هڪ واحد WhatsApp ان باؤنڊ جو تصديق سان گڏ نئون ٽڪيٽ بڻجڻ ڏيکاري ٿي. ساڳئي شڪل هر چينل تي لاڳو ٿيندي آهي؛ صرف ريسيور ۽ تصديق ايڊاپٽر بدلجن ٿا.

sequenceDiagram autonumber participant Sender as Sender (WhatsApp) participant WA as WhatsApp Cloud API participant RCV as Inbound Webhook Receiver participant Q as Intake Queue (BullMQ) participant ID as Identity Linking participant DEDUP as Dedup Service participant AI as AI (PII · categorize · lang) participant TKT as Ticketing Core participant NOT as Notifications (fallback) Sender->>WA: sends complaint text + photo WA->>RCV: webhook (signed) RCV->>RCV: verify X-Hub-Signature-256, replay check, rate-limit gate RCV->>Q: enqueue InboundMessage Q->>AI: PII detect + redact (photo OCR'd) Q->>ID: resolve phone → rep/org or Provisional ID-->>Q: resolved identity Q->>DEDUP: similarity vs open + recent tickets DEDUP-->>Q: no confident match Q->>AI: categorize + routing + urgency + language AI-->>Q: suggestions + locale Q->>TKT: create ticket (channel_of_origin=whatsapp, locale, attachments) TKT-->>Q: tracking ID SITP-2026-ITD-000045 Q->>NOT: confirm on WhatsApp (fallback: SMS → email) NOT->>WA: send ticket_created_sd template WA->>Sender: "Your ticket SITP-2026-ITD-000045 is registered"

ريسيور دستخط جي تصديق ڪري ٿو ۽ ڪنهن به پائپ لائن ڪم کان اڳ ريٽ لِمٽ گیٽ لڳائي ٿو (مرحلا 2–3). PII حذف ڪنهن به ڪلائوڊ AI ڪال کان اڳ هلندي آهي (مرحلو 5). سڃاڻپ ۽ ڊي ڊپ درجه بندي سان گڏ متوازي هلندا آهن جتي ڊيٽا انحصار اجازت ڏئي. تصديق آخري مرحلو آهي، ڪراس چينل فال بیک (§12) سان ته جيئن تصديق جي وقت WhatsApp بند ٿيڻ سان موڪليندڙ پھسڻ ناهي.

17. غير فعالتي ضرورتون (MCI مخصوص)

اهي NFRs سسٽم وسيع NFRs (03-non-functional-requirements/en.md) ۽ انٽيگريشن NFRs (/specs/sd/08-integrations-spec/ §11) کي ملٽي چينل انٽيڪ سطح لاءِ بهتر ڪن ٿيون.

آءِ ڊي	تشوش	هدف
`NFR-MCI-001`	ان باؤنڊ ingestion latency	فراهم ڪندڙ تائين ack ≤ 2 s p95 (ته جيئن فراهم ڪندڙ جو ويب هوڪ ٽائم آئوٽ ناهي ٿيندو)؛ پائپ لائن ڪم async هلندو آهي.
`NFR-MCI-002`	اينڊ ٽو اينڊ تخليق latency (وصولي → ٽڪيٽ بڻيو)	غير AV-heavy ان باؤنڊ لاءِ ≤ 30 s p95؛ جڏهن منسلڪات AV + OCR گهرجن ≤ 60 s p95.
`NFR-MCI-003`	تصدیق ترسيل	ٽڪيٽ تخليق کان ≤ 60 s p95؛ فال بیک چين فراهم ڪندڙ ٽائم آئوٽ کان پوءِ شروع.
`NFR-MCI-004`	دستيابي	انٽيڪ plane ≥ 99.9%؛ ڪنهن به واحد فراهم ڪندڙ جي بندشي ٻين چينلز جي انٽيڪ کي خراب ناهي ڪندي.
`NFR-MCI-005`	Idempotency	هر ان باؤنڊ فراهم ڪندڙ پيغام آءِ ڊي سان keyed؛ ري پلے بالڪل هڪ ڀيرو create/update.
`NFR-MCI-006`	آف لائن حاصل ڪرڻ جي لچڪ	پيرين اندراج ڊوائيس reboot، app kill، ۽ > 24 ڪلاڪ آف لائن کان بچي ويندا آهن؛ سنڪ ناڪامي تي ڪو به اندراج ضايع ناهي ٿيندو.
`NFR-MCI-007`	پرائيويسي	ان باؤنڊ پے لوڊ ڪنهن به ڪلائوڊ AI ڪال کان اڳ PII حذف؛ خام پے لوڊ encrypted اسٽور؛ رسائي لاگ.
`NFR-MCI-008`	آڊٽABILITY	هر ان باؤنڊ `int_call` ۾ رڪارڊ؛ هر create/append فيصلو (ڊي ڊپ انتخاب سميت) `audit_events` ۾.
`NFR-MCI-009`	مشاهدگي	هر چينل ڊيش بورڊس (حجم، latency، errors، DLQ گهرائي، spam-held)؛ بي ضابطگين تي الرٽس.
`NFR-MCI-010`	انصاف	چينلِ اصليت SLA، روٽنگ ترجيح، يا RBAC بدل ناهي ڪندي؛ هر ريليز تي خودڪار ٽيسٽ سان تصديق.

18. FR traceability

هي دستاويز /specs/sd/02-functional-reqs/ §MCI ۾ MCI ماڊيول FRs جي تفصيلي توسيع آهي.

FR	عنوان	MoSCoW	حاصل ٿيل مقام
`FR-MCI-001`	ان باؤنڊ اي ميل مان ٽڪيٽ ٺاهيو	[M]	§5.1، §6، §7
`FR-MCI-002`	WhatsApp ۽ SMS مان ٽڪيٽ بنا ۽ اپ ڊيٽ ڪريو	[M]	§5.2، §5.3، §6، §7
`FR-MCI-003`	ٽول فري IVر/وائس انٽيڪ فراهم ڪريو	[S]	§5.4، §6
`FR-MCI-004`	عملدار جي طرفان پيرين/آف لائن انٽيڪ فراهم ڪريو	[M]	§5.5، §13، §6
`FR-MCI-005`	انٽيڪ تي چينلز جي وچ ۾ نقل سڃاڻيو	[M]	§3.3 (مرحلو 4)، §11
`FR-MCI-006`	هر ٽڪيٽ تي چينلِ اصليت حاصل ڪريو	[M]	§4 (meترڪس)، §6، §15
`FR-MCI-007`	ان باؤنڊ موڪليندڙن جي ريٽ لِمٽ ۽ تصديق	[M]	§3.3 (گیٽ)، §10

ڪراس ڪٽنگ FRs جن تي انحصار آهي: FR-TKT-001 (ٽريڪنگ آءِ ڊيز)، FR-TKT-006 (گمنام حيثيت lookup، IVر جي استعمال ٿيل)، FR-TKT-007/FR-TKT-008 (SLA + اسڪيليشن، چينل کان آزاد)، FR-TKT-015/FR-TKT-017 (ضم + link)، FR-FILE-003/FR-FILE-004 (AV + encrypted اسٽوريج)، FR-AI-002/FR-AI-003/FR-AI-004/FR-AI-006/FR-AI-007/FR-AI-009 (AI صلاحيتون)، FR-ORG-009 (حساس پيرين لاءِ step-up)، FR-NOT-001/FR-NOT-003 (اطلاعات + ان باؤنڊ جواب منسلڪ).

19. کليل سوالات / TBD

#	شيءِ	حيثيت
1	ٽول فري نمبر الاٽمينٽ ۽ IVر پليٽ فارم وينڊر (ڪلائوڊ IVر بمقابله آن پريم PBX).	TBD (خريداري).
2	IVر/وائس نوٽس لاءِ STT فراهم ڪندڙ — ڪلائوڊ (Azure/Google/AWS) بمقابله self-hosted (Whisper/Vosk) UR/SD ڪوالٽي جي پیشِ نظر.	AI pluggability پاليسي سان TBD.
3	ڇا SMS انٽيڪ کي short-code گهرجي يا موجوده sender-ID reverse رستو ٻيهر استعمال ڪري سگهي ٿو.	ايگريگيٽر سان TBD.
4	عارضي سڃاڻپ ضم semantics جڏهن ساڳيو شخص پوءِ ڪنهن ٻي org هيٺ rep رجسٽر ڪري.	ORG ماڊيول سان TBD.
5	ڇا IVر ڪال بیک قطار سهولت ڪار جي دستيابي لاءِ Internal Comms presence (ماڊيول F) سان integrate ٿئي.	TBD.
6	شفافيت ڊيش بورڊ تي چينل mix تجزيات لاءِ پبلڪ دٻاءُ حدون.	تجزيات پاليسي سان TBD.
7	ڊيٽا درجه بندي پاليسي مطابق خام ان باؤنڊ پے لوڊ (`subject_raw`، `body_raw`، آڊيو) retention.	`/specs/sd/11-security-compliance/` سان TBD.

دستاويز جو اختتام.