ملٹی چینل انٹیک

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

خانہ	قدر
دستاویز آئی ڈی	19
حیثیت	ڈرافٹ
مالک	S&ITD / MAAHIR
زبانیں	EN (استاد) · UR · SD
ماڈیول پر لاگو	K — ملٹی چینل انٹیک (MCI)
متعلقہ دستاویزات	`/specs/ur/02-functional-reqs/` (MCI FRs)، `/specs/ur/08-integrations-spec/` (Mailjet/SMS/WhatsApp معاہدے)، `/specs/ur/06-ticket-workflow/`، `/specs/ur/15-tech-architecture/`، `/specs/ur/05-data-model/`، `/specs/ur/11-security-compliance/`، `/specs/ur/24-trust-safety/`
حاصل کرتا ہے	`FR-MCI-001` … `FR-MCI-007`

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

یہ دستاویز پورٹل کی زیرِ-support ہر چینل پر انٹیک کے لیے واحد مستند ماخذ ہے۔ یہ تعین کرتی ہے کہ کیا چیز چینل شمار ہوتی ہے، ایک پیغام کس طرح ٹکٹ بنتا ہے (یا کسی ٹکٹ سے منسلک ہوتا ہے)، ایک ہی شکایت جو دو مختلف چینلز کے ذریعے دو بار دائر کی گئی ہو کس طرح پہچانی اور ضم کی جاتی ہے، اور نظام کس طرح دستیاب رہتا ہے حتیٰ کہ جب کوئی انفرادی فراہم کنندہ ڈاؤن ہو۔

پورٹل کا مقامی ویب انٹیک فارم اور پارٹنر پبلک REST API (POST /api/v1/tickets، دیکھیں /specs/ur/12-api-contract/) بنیادی انٹیک راستے ہیں اور مکمل طور پر /specs/ur/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/ur/06-ticket-workflow/ §15 کے مطابق ہر محکمے کے لیے کنفیگر کی جا سکتی ہیں۔

2. اصول — کمپنیوں سے وہیں ملیں جہاں وہ ہیں

پورٹل کا مفاد حکومتِ سندھ کے ساتھ IT انڈسٹری کے مسائل حل کرنے کے لیے ایک سنگل ونڈو رکھنا ہے۔ ایک سنگل ونڈو جو صرف لاگ اِن شدہ ویب فارم کے ذریعے جمع شدگی قبول کرے، عملی طور پر سنگل ونڈو نہیں ہے — یہ ایک رکاوٹ ہے۔ پاکستانی IT کمپنیاں، فری لینسرز، اور ان کے ساتھ تعامل رکھنے والے شہری کسی پورٹل میں نہیں رہتے؛ وہ WhatsApp، SMS، ای میل، اور فون میں رہتے ہیں۔ کوئی فیلڈ افسر جو کسی سافٹ ویئر پارک کا دورہ کر رہا ہو، ہمیشہ کنکٹیویٹی نہیں رکھتا۔

لہٰذا ملٹی چینل انٹیک ماڈیول چار لازمیتوں پر عمل کرتا ہے:

آئی ڈی	لازمیت	معنی
MC-1	ہر چینل ایک ہی ٹکٹ پیدا کرتا ہے۔ کوئی "ای میل ٹکٹ" نہیں، کوئی "WhatsApp ٹکٹ" نہیں۔ WhatsApp سے بنا ٹکٹ وہی ریکارڈ ہے، وہی ٹریکنگ آئی ڈی فارمیٹ، SLA، اسکیلیشن لیڈر، حل کے ثبوت کا گیٹ، آڈٹ ٹریل، اور تجزیاتی ابعاد، جو ویب فارم سے بنا ہو۔
MC-2	سنا جانے کے لیے لاگ اِن ضروری نہیں۔ غیر رجسٹرڈ یا غیر مصدقہ بھیجنے والا ہمیشہ ان باؤنڈ چینل کے ذریعے درج کروا سکتا ہے؛ نظام ایک عارضی شناخت بناتا ہے اور بعد میں رجسٹریشن کی پیشکش کرتا ہے۔ تصدیق اعتماد بڑھاتی ہے، رسائی نہیں۔
MC-3	آمد کے چینل میں جواب دیں۔ وصولی تصدیقیں، حیثیت کی اپڈیٹس، اور افسران کے پیغامات بھیجنے والے تک اس چینل پر پہنچتے ہیں جس کا استعمال اس نے پورٹل سے رابطے کے لیے کیا، اور اگر وہ چینل خراب ہو تو کراس چینل فال بیک موجود ہے۔
MC-4	چینل ڈیٹا ہے، مقدر نہیں۔ چینلِ اصلیت ریکارڈ، تجزیہ، اور آڈٹ کی جاتی ہے — مگر کبھی کسی ٹکٹ کے حقوق، SLA، یا روٹنگ منطق کو نہیں بدلتی۔ کوئی ٹکٹ اس لیے "کم اہم" نہیں کہ وہ SMS سے آیا۔

ان لازمیتوں کا حوالہ اس دستاویز بھر میں آئی ڈی سے دیا گیا ہے اور /specs/ur/02-functional-reqs/ §MCI کے قبولیت کے معیارات میں۔

3. انٹیک پائپ لائن

3.1 جائزہ

چینل سے قطعِ نظر، ہر ان باؤنڈ پیغام ٹکٹ یا تبصرہ بننے سے پہلے اسی سات مرحلوں کی پائپ لائن سے گزرتا ہے۔ یہ پائپ لائن ایک BullMQ ورکر چین کے طور پر نافذ کی گئی ہے؛ ہر مرحلہ idempotent ہے، آزادانہ طور پر retryable ہے، اور ایک audit_events قطار emit کرتا ہے۔ مراحل یہ ہیں:

انجسٹ (Ingest) — چینل ایڈاپٹر سے خام پے لوڈ وصول کریں (Mailjet ان باؤنڈ parse، SMS MO، WhatsApp Cloud API ویب ہوک، IVR ریکارڈنگ کال بیک، 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/ur/08-integrations-spec/ §9.2 میں بیان کردہ ان باؤنڈ ویب ہوک ریسیور تک پہنچایا جاتا ہے — ایک واحد سامنے کا دروازہ جو فراہم کنندہ کے دستخط کی تصدیق کرتا ہے، ری پلے مسترد کرتا ہے، اور انٹیک قطار پر ایک نارمالائزڈ لفافہ بھیجتا ہے۔ ریٹ-لِمٹ / اینٹی اِیوز گیٹ (§10) ریسیور پر لگایا جاتا ہے، کسی بھی مہنگے کام سے پہلے؛ ایک بھیجنے والے کی سیلابیں پائپ لائن تک پہنچنے سے پہلے چھوڑ دی جاتی یا تھروٹل کی جاتی ہیں۔

انجسٹ ورکر لفافہ پڑھتا ہے، اسے (حساسی خانے حذف شدہ) int_call میں direction inbound کے ساتھ ریکارڈ کرتا ہے، اور خام پے لوڈ نارمالائز مرحلے کو دیتا ہے، جو ایک معیاری InboundMessage تیار کرتا ہے جس میں شامل ہیں: بھیجنے والے کے شناختگر (ای میل، MSISDN، WA-verified نام، CNIC اگر ظاہر کیا، rep آئی ڈی اگر ملاپ ہو)، خام موضوع/باڈی، منسلکات (staging بکٹ میں presigned refs)، لوکیل اشارے (ای میل کے لیے Accept-Language، WA کے لیے ڈیوائس لوکیل، SMS کے لیے پہچانی اسکرپٹ، IVR کالر کی طرف سے بیان کردہ زبان)، اور چینل مخصوص میٹا ڈیٹا (پیغام آئی ڈی، جواب کا سیاق، in-reply-to/References ہیڈرز، IVR کال آئی ڈی، پیدل افسر آئی ڈی)۔

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. چینل کی صلاحیتیں (میٹرکس)

پانچ ان باؤنڈ چینلز بینڈوڈتھ، منسلکات کی support، دو طرفہ صلاحیت، اور ریگولیٹری انحصار میں مختلف ہیں۔ نیچے دی گئی جدول وہ صلاحیت کا معاہدہ ہے جو ہر چینل ایڈاپٹر کو پورا کرنا ہے؛ ہر چینل کی تفصیلات §5 میں ہیں۔

صلاحیت	ای میل	SMS	WhatsApp	IVR / وائس	پیدل / آف لائن
چینل کوڈ (`channel_of_origin`)	`email`	`sms`	`whatsapp`	`ivr`	`walkin`
ٹرانسپورٹ	Mailjet ان باؤنڈ parse	MO تا short-code	WA Cloud API ویب ہوک	ٹول فری PSTN	PWA سنک بیچ
سمت	دو طرفہ (جواب منسلک)	دو طرفہ (جواب منسلک)	دو طرفہ (جواب منسلک)	یک طرفہ اِن + SMS/وائس آؤٹ	دو طرفہ (افسر کی طرف سے اندراج)
منسلکات support	کسی بھی قسم کی (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)	ہاں (کوئی بھی اسکرپٹ + وائس نوٹس)	ہاں (IVR 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 فراہم کنندہ، IVR پلیٹ فارم	PWA آف لائن اسٹوریج + سنک ورکر
حیثیت	`contracted`	`contracted`	`planned` (WABA زیرِ التواء)	`planned` (Phase 4، `/specs/ur/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/ur/06-ticket-workflow/ اور /specs/ur/12-api-contract/ میں دستاویز کردہ ہیں؛ انجسٹ کے بعد یہ اسی پائپ لائن میں شامل ہوتے ہیں اور یہاں دوبارہ متعین نہیں کیے گئے۔

5. ہر چینل کی تفصیلات

ہر چینل کو /specs/ur/08-integrations-spec/ §3 کے انٹیگریشن ٹیمپلیٹ کے خلاف بیان کیا گیا ہے تاکہ معاہدے موازنہ پذیر ہوں۔ جہاں بنیادی ٹرانسپورٹ پہلے ہی /specs/ur/08-integrations-spec/ §5 میں متعین ہے (Mailjet، SMS، WhatsApp)، یہ سیکشن صرف اس کے اوپر رکھی گئی انٹیک مخصوص رویے کا احاطہ کرتا ہے۔

5.1 ای میل سے ٹکٹ

خانہ	قدر
مقصد	سہولت ڈیسک پتے پر ای میل کے ذریعے شکایات، فالو اپس، اور ثبوت وصول کریں؛ ہر ان باؤنڈ کو نیا ٹکٹ یا منسلک جواب بنائیں؛ منسلکات محفوظ رکھیں۔
سمت	ان باؤنڈ (Mailjet ان باؤنڈ parse → SITP) دو طرفہ جوابات کے ساتھ (افسر ای میل سے جواب دیتا ہے تو اسی ٹکٹ تھریڈ سے منسلک ہوتا ہے)۔
تصدیقی طریقہ	Mailjet ان باؤنڈ پر DKIM/SPF تصدیق کرتا ہے؛ SITP میل جیٹ ویب ہوک دستخط کی تصدیق کرتا ہے (`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 ٹول فری IVR / وائس

خانہ	قدر
مقصد	ٹول فری، اسمارٹ فون کے بغیر انٹیک راستہ فراہم کرنا؛ شکایات کو وائس ریکارڈنگز کے طور پر حاصل کریں، انہیں transcribe کریں، ٹکٹ بنائیں؛ کالرز کو آئی ڈی سے موجودہ ٹکٹ کی حیثیت تلاش کرنے دیں؛ جب ایجنٹ دستیاب نہ ہو تو کال بیک قطار۔
سمت	ان باؤنڈ (PSTN → IVR → SITP کال بیک) + آؤٹ باؤنڈ (SMS تصدیق، شیڈولڈ وائس کال بیک)۔
تصدیقی طریقہ	کالر آئی ڈی (MSISDN) شناخت کا اشارہ ہے؛ CNIC کو زیادہ اعتماد والے اقدامات کے لیے DTMF کے ذریعے حاصل کیا جا سکتا ہے۔
نمبر	ایک واحد ٹول فری نمبر (مثلاً `0800-SITP`) پبلک سائٹ اور تمام چینل فوٹرز پر شائع کیا گیا۔
IVR کال فلو	(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 support کرتا ہے۔
تصدیق	کالر کو SMS نیا ٹریکنگ آئی ڈی اور منسلکات/CNIC شامل کرنے کے مختصر لنک کے ساتھ (`§5.2` کے ہم مرتبہ)۔
حیثیت look up	صرف پبلک حیثیت کی معلومات پڑھتا ہے (`FR-TKT-006`)؛ فون پر کالر کی دی گئی معلومات سے زیادہ کوئی PII نہیں پڑھی جاتی۔
کال بیک قطار	کالر MSISDN، بیان کردہ زبان، اور ترجیحی سلاٹ کے ساتھ زیرِ التواء کال بیکس کی BullMQ قطار؛ دستیاب سہولت کار اگلا کال بیک claim کرتا ہے اور نظام آؤٹ باؤنڈ کال لگاتا ہے۔
اینٹی اِیوز	ہر MSISDN ریٹ لِمٹس (`§10`)؛ ضرورت سے زیادہ مختصر کالز چھوڑ دی جاتی ہیں؛ بدتمیز کالرز جائزے کے لیے نشان زد ہوتے ہیں۔
حیثیت	`planned` — `/specs/ur/08-integrations-spec/` §12.4 کے مطابق Phase 4 (ٹول فری نمبر، IVR پلیٹ فارم، 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/ur/05-data-model/ دیکھیں)۔ نیچے کی جدول مستند فیلڈ میپ ہے۔ جہاں کسی چینل کے پاس کسی فیلڈ کی کوئی مقامی قدر نہیں ہوتی، پائپ لائن اسے AI (§3.3 مرحلہ 5) سے بھرتی ہے یا ٹرائج کے لیے چھوڑ دیتی ہے۔

ٹکٹ فیلڈ	ای میل ماخذ	SMS ماخذ	WhatsApp ماخذ	IVR / وائس ماخذ	پیدل ماخذ
`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 پیغام آئی ڈی	IVR کال آئی ڈی	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 ظاہر کرتا یا لے کر آتا ہے (IVR 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/ur/06-ticket-workflow/ §4–§5 دیکھیں)۔ واحد چینل آگاه رویہ فال بیک تصدیق (§12) ہے۔

دو ضمانتیں لاگو ہوتی ہیں:

کسی کم بینڈوڈتھ چینل (SMS، IVR) سے بنا ٹکٹ روٹنگ یا SLA میں اس لیے سزا نہیں پاتا کہ اس میں لمبی تفصیل نہیں۔ AI خلاصہ + افسر ٹرائج روٹنگ حتمی ہونے سے پہلے تفصیل میں اضافہ کرتے ہیں؛ FRT گھڑی ٹرائج مکمل ہونے تک شروع نہیں ہوتی (/specs/ur/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 نہیں ہوتا۔

IVR کال کے آغاز پر ایک کالر کی بیان کردہ زبان شامل کرتا ہے؛ IVR 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/ur/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، IVR/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۔
پبلک حیثیت	پبلک حیثیت پیج (اور IVR حیثیت-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/ur/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 پروڈکٹ	کتنی بار پیدل/IVR/SMS فائل کرنے والا رجسٹر ہوتا ہے۔
ان باؤنڈ تصدیق کامیابی شرح	دن × چینل	ops	`§12` فال بیک چین tuning چلاتی ہے۔
سپیم/اِیوز روکا	دن × چینل	ops / ٹرسٹ و سیفٹی	جائزہ قطار میں حجم (`§10`)۔
ڈی ڈپ / ضم شرح	ہفتہ × چینل	S&ITD پروڈکٹ	کتنے کراس چینل نقل پکڑے جاتے ہیں۔
آف لائن-سنک lag	دن × افسر	ops	پیدل کے لیے حاصل کرنے اور سنک کے درمیان زیادہ سے زیادہ وقت (`§13`)۔

تمام چینل میٹرکس اپنے چینل سے آزاد ہم مرتبوں کے ساتھ وہی تعریفیں اور rounding قواعد شیئر کرتے ہیں (AP-5)؛ واحد اضافی بُعد channel_of_origin ہے۔

15. ڈیٹا ماڈل ٹچ پوائنٹس

یہ دستاویز ڈیٹا ماڈل دوبارہ تعین نہیں کرتی (/specs/ur/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/IVR کال/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. اینڈ ٹو اینڈ sequance (ایک ان باؤنڈ → ایک ٹکٹ)

نیچے کی 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/ur/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/ur/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`	ٹول فری IVR/وائس انٹیک فراہم کریں	[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 (میٹرکس)، §6، §15
`FR-MCI-007`	ان باؤنڈ بھیجنے والوں کی ریٹ لِمٹ اور تصدیق	[M]	§3.3 (گیٹ)، §10

کراس کٹنگ FRs جن پر انحصار ہے: FR-TKT-001 (ٹریکنگ آئی ڈیز)، FR-TKT-006 (گمنام حیثیت lookup، IVR کے استعمال شدہ)، 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	ٹول فری نمبر الاٹمنٹ اور IVR پلیٹ فارم وینڈر (کلاؤڈ IVR بمقابلہ آن پریم PBX)۔	TBD (خریداری)۔
2	IVR/وائس نوٹس کے لیے STT فراہم کنندہ — کلاؤڈ (Azure/Google/AWS) بمقابلہ self-hosted (Whisper/Vosk) UR/SD کوالٹی کے پیشِ نظر۔	AI pluggability پالیسی کے ساتھ TBD۔
3	کیا SMS انٹیک کو short-code چاہیے یا موجودہ sender-ID reverse path دوبارہ استعمال کر سکتا ہے۔	ایگریگیٹر کے ساتھ TBD۔
4	عارضی شناخت ضم semantics جب وہی شخص بعد میں کسی اور org کے تحت rep رجسٹر کرے۔	ORG ماڈیول کے ساتھ TBD۔
5	کیا IVR کال بیک قطار سہولت کار کی دستیابی کے لیے Internal Comms presence (ماڈیول F) کے ساتھ integrate ہو۔	TBD۔
6	شفافیت ڈیش بورڈ پر چینل mix تجزیات کے لیے پبلک دباؤ حدود۔	تجزیات پالیسی کے ساتھ TBD۔
7	ڈیٹا درجہ بندی پالیسی کے مطابق خام ان باؤنڈ پے لوڈ (`subject_raw`، `body_raw`، آڈیو) retention۔	`/specs/ur/11-security-compliance/` کے ساتھ TBD۔

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